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ABSTRACT 





Maneuver element communications can be divided into 
Single-Channel Voice, Data Networks, and Telephony. 
Classified computer networks, such as SIPRNET are pushed to 
Infantry and Artillery Battalions via the EPLRS- radio 


system. However, telephone services may or may not be 





supported due to limited availability of Multi-Channel 


Digital assets. Single-Channel Radio is utilized to 
communicate with higher, adjacent and subordinate 
organizations. While this is a sufficient means of 


communications, it is half-duplex, cumbersome, unreliable, 


and subject to availability due to net traffic. Voice over 





IP may be the solution to deploy full duplex telephone 
communications services to bandwidth deprived 


organizations, via an existing wireless network 





infrastructure. The development and testing of a software 


based “VoIPNET” prototype proved the EPLRS Network’s 





ability to provide critical primary telephone services, via 





VoIP, to highly mobile maneuver elements. Detailed 


requirements analysis and design specifications were 





developed for future development of the VoIPNET 
application. In addition, the results of VoipNET Prototype 
tests on an EPLRS network are compiled into deployment 
recommendations for units attempting to establish VoIP on 


an EPLRS network. 
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i BACKGROUND AND VISION 


A. INTRODUCTION 





Maneuver element communications can be divided into 
Single-Channel Voice, Data Networks, and Telephony. 
Infantry Regiments currently possess the capability to draw 
sufficient bandwidth to support robust Data and Telephone 
networks, providing access to classified and unclassified 
data/telephone systems. Classified computer networks, such 


as SIPRNET are pushed to Infantry and Artillery Battalions 





via the EPLRS radio system. However, telephone services may 
or may not be supported due to limited availability of 
Multi-Channel Digital assets. As a result, the Maneuver 
Element’s primary means of voice communications media is 


Single-Channel Radio. 


Single-Channel Radio is utilized to communicate with 
higher, adjacent and subordinate organizations. While this 
is a sufficient means of communications, it is half-duplex, 
cumbersome, unreliable, and subject to availability due to 
net congestion. Therefore, the preferred media for 
Commanders and Staff is full duplex telephone 
communications. With the advent of EPLRS and the increasing 


availability of bandwidth at the lower echelons of command, 





it is advantageous to consider the utilization of existing 





data networks to provide telephone connectivity to units 





that do not have access to switched telephone services. 
Voice over IP may be the solution to deploy full duplex 
telephone communications services to bandwidth deprived 
organizations, via an existing wireless network 


infrastructure (EPLRS). The development of a software based 
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“VoIPNet” would provide critical primary telephone services 





to highly mobile maneuver elements and redundant telephone 


networks for units with switched telephone services. 





This Thesis will identify, analyze, and document the 


requirements for an open source VoIP application capable of 





supporting both Voice and Video services over the EPLRS 


network. 


Chapter I: Background information and the Vision of 


the thesis and application. 


Chapter Tass System features and performance 


requirements will be developed and analyzed. 


Chapter III: Supplemental Requirements Specifications 


will increase the granularity of the Requirement topics 





from Chapter II. 


Chapter IV: The Risk Management Plan will identify, 
analyze, and plan for potential pitfalls during the 


development of the Application. 


Chapter V: The System Design Specification will 
provide the static and dynamic characteristics of the 


application. 


Chapter VI: The Testing Plan will detail the 





procedures followed and features tested for the prototype. 
The initial testing will focus on prototype usability and 
suitability, while the operational testing will attempt to 


prove the EPLRS networks supportability of VoIP services. 


Chapter VII: The Test Report will document the results 


of the Initial and Operational Prototype Testing. 


Chapter VII: The Conclusion will summarize the 
findings of the test report and make deployment 


recommendations. 


A prototype will be developed or an open source 





application chosen, that is capable of proving the concept 





of VoIP during the operation testing phase. Peer-to-peer, 


Video Teleconference and the EPLRS network’s ability to 





support multiple simultaneous voice and video calls will be 
tested. 
de Purpose of the Vision Document 


The purpose of this document is to collect, analyze, 
and define high-level user needs and application features 
for VoIPNET. 


2. Overview of the VoIPNET Application 


The VoIPNET application is intended to increase the 





quality of communications at the lower echelons of command. 
It will provide full-duplex voice communication, peer-to- 


peer video teleconferencing, file transfer, and “chat” 





functionality. 


3. References 


[1] “Managing Software Requirements.” Leffingwell & 





Widrig. 


B. USER DESCRIPTION 


The VoIPNET application users are a collection of 
infantry, artillery, aviation and support organizations 


within the United States Military. Common to all users is 


the utilization of low-bandwidth, mobile radio 


communications, capable of data transmission at low rates. 


1. User Demographics 


The U.S. Military is progressing towards “net-centric” 
warfare. As bandwidth to lower echelons of command 
increase, so does the opportunity to develop new software 
tools to increase the quality of communications. Current 
projects underway include: Command and Control On-the-move 
Network Digital Over-the-horizon Relay (CONDOR) and the 
Joint Tactical Radio System (JTRS). Both programs are 
focused on pushing existing Command and Control Networks to 


the lowest echelons of Tactical Command. 





2. User Profiles 
a. Infantry Regiments/Brigade 


The brigade or regiment is made up of two to five 
battalions under the command of a Colonel with a Sergeant 
Major as the senior non-commissioned officer. Armored 


cavalry, Ranger units and USMC infantry units of similar 





size to a brigade are called Regiments. Special-forces 
units are known as groups. Each Regiment/Brigade has a 
Command Staff composed of Administrative, Intelligence, 


Operations, Logistics, and Communications representatives. 


b. Infantry Battalion/Squadron 





The primary combat maneuver element, the 
battalion or squadron is composed of four to six companies 
and is commanded by a Lieutenant Colonel with a Sergeant 
Major as the senior non-commissioned adviser. The Executive 
Officer is a Major and second in command. The battalion is 
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tactically and administratively self-sufficient and can 
conduct independent operations of a limited scope. 
Battalion sized armored and air cavalry units (U.S. Army) 
and all aviation units (USMC) are referred to as squadrons. 
Each Battalion/Squadron has a Command Staff composed of 
Administrative, Intelligence, Operations, Logistics, and 


Communications representatives. 


c. Infantry Company 


Company (in the infantry), battery (in the 
artillery) or troop (in the cavalry): The company, battery 
or troop is made up of three to five platoons and is 
typically commanded by a Captain. It usually has a First 
Lieutenant as the second in command and a First Sergeant as 


the senior non-commissioned officer. 


3. Users Environment 


The U.S. Military continues to be engaged in areas of 
operation that prove difficult for half—-duplex 
communications. Urban terrain is an ideal environment to 
deploy a low-bandwidth data network for VoIPNET services. 
The U.S. Military currently uses the EPLRS (Enhanced 
Position Location Radio System) network for maneuver 


element access to the tactical network. 


EPLRS Radio Sets (RSs) are primarily used as jam-— 
resistant, secure data radios that transmit and receive 
tactical data that typically includes Operations orders, 
Fire support plans, Logistics reports, Situation Awareness 
(SA) data, Cryptographic keys for RSs, Configuration files 


for RSs, and E-mail. 
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EPLRS NEEDLINES: 

(COMPANY TO COMPANY) 
NOTE: 
NEEDLINES MAY BE POINT-TO-POINT (SET UP 
BETWEEN TWO RSs) OR MANY-TO-MANY 
(SET UP FOR A GROUP OF RSs) 

Figure 1. Sample EPLRS Network (U.S. Army, 2004). 
Figure 2. 


EPLRS utilizes the Time Division Multiple Access 
(TDMA) architecture. Each radio is assigned one or more 


time slots called Logical Time Slots (LTS) in which it will 





transmit its data onto the needline while the remaining 


radios listen. 


Needlines 


EPLRS RSs automatically route and deliver tactical 
data using multiple concurrent communication paths called 
needlines. A needline is a common set of time and frequency 
resources shared among two or more RSs to exchange data. A 
needline is the fundamental line of communication set up 


between individuals or groups of EPLRS RSs. 


The needlines can be Many- to-Many, Few- to-Many or 





One- to-One. A single RS can support up to 32 needlines at 


the same time, but the maximum number is usually 28. Host 





computers can send and receive information too and receive 
from, many other host computers on the EPLRS network 
because the RSs can support many concurrent needlines via 
time division and frequency division multiplexing. RSs 
support needlines by sourcing data, receiving data or 
relaying data for other RSs. An RS can be a relay on some 
needlines and be a source or destination for data on other 


needlines virtually at the same time. 





Fach EPLRS network has a needline and corresponding 


Communication Circuit Assignments (CCA) to describe the 








characteristics of that needline. There are two basic types 


of needlines: point-to-point and broadcast. The two 





needline types are further sub-divided into several types: 


CSMA- Carrier Sense Multiple Access provides a single 
cloud and shares bandwidth with all users. Each user has 
the ability to transmit and receive data at all times. This 
provides increased bandwidth flexibility but is also prone 
to resource “hogging” by high bandwidth applications or 
users. It is possible for a single user to consume all 


available bandwidth. Hop limits are programmed during EPLRS 
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network planning. CSMA hops come at a price. Each planned 
hop on a CSMA network cuts the network’s available 
bandwidth in half. A CSMA needline must use the same 
resources to support the source and destination RSs and the 
additional relays. For example, a CSMA network with O hops 
may provide 400kbps available bandwidth. However, the same 
network configuration with a single planned hop provides 


only 200kbps of bandwidth. 





Figure 3. CSMA Many-to-Many Architecture (U.S. Army, 
2004). 


MSG- Multiple Source Group is a restricted CSMA. It 
separates the users into “core” and “fringe” members. 
“Core” members of the MSG have the ability to transmit and 
receive data at a predetermined data rate. “Fringe” members 


typically can receive only. Membership is determined by the 


allocation of shares. The network planner can allocate up 
to sixteen total shares. The more shares a user is 
allocated, the more bandwidth available. Advanced settings 
allow the redistribution of unused shares to other users. 
Converse to a CSMA needline, you can add relays to a Multi- 
Source Group (MSG) needline and see no reduction in 


throughput. The MSG needline uses an additional channel 








resource to support the relay. This has the added benefit 
of restricting the available bandwidth to each user and 


preventing resource “hogging.” 





Figure 4. MSG Few-to-Many Architecture (U.S. Army, 
2004). 


DAP— Dynamic Permanent Virtual Circuit utilizes a 
single LTS to find and coordinate a virtual circuit between 


two radios. When the route is discovered it is added to the 


routing table and the DAP LTS is released. The data is then 


passed over a separate LTS. 


HDR- High Data Rate Duplex circuits are static routes 
between radios, typically used to connect independent EPLRS 
networks. They are reliable networks with receipt delivery 
messages and packet retransmission. This aspect makes them 


unsuitable for VoIP applications. 





Figure 5. Point-to-Point Architecture (U.S. Army, 
2004). 


LDR- Low Data Rate Duplex circuits are similar to HDRs 


except for a lower data rate. 
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Broadcast circuit, 
one-to-one and 

many -to-many, 
automatic contention 
and collision reduction; 
no RS acknowledge- 
ment of data. 


Overall 
Characteristics 


Relay 
Characteristics 


Up to 5 relays, 
selectable; automatic 
relay negotiation by 
needline participants. 


Bandwidth 1/4, 1/2, 1, 2, 4, or 8 
LTS (bandwidth 
reduction for more 


relays). 


Reliability No RS acknowledge. 
High reliability reduces 


bandwidth by 25%. 


Planning 
Considerations 


Easy to plan, easy to 
enter into ENP, easy to 
deploy, relaying 
performed by RSs on 
needline. 


Advantages Different relay 
schemes provide 
flexibility, minimum 
planning, supports 
one-to-one and 


many -to- many traffic. 


Figure 6. 


Needline Comparison Chart 


One-to-one balanced, 
one-to-one, RS 
acknowledge, no 
contention or collision. 


Broadcast needline, 
few-to-many (max of 
4, 8, or 16 sources at 
any one time), no 
contention or collision, 
guaranteed or 
dynamic bandwidth 
allocation available. 


Pipeline, up to 5 
relays, selectable; 
automatic relay 
negotiation by 
needline participants. 


Pipeline, if needline is 
one LTS or less, 
automatic negotiate 4 
relays (5 hops). If 
needline is 2 or 4 
LTSs, automatic 
negotiate 3 relays (4 
hops). If more relays 
needed planner can 
configure up to 5 static 
relays in ENP. 


1/4, 1/2, 1, 2. 4, or 8 
LTS; source allocation 
assignment (no 
bandwidth reduction 
for more relays). 


1/4, 1/2, 1, 2, or 4, LTS 
(bandwidth reduced 
for 5 relay option not 3 
relay option). 


No R&S acknowledge. | Very high reliability 
(RSs acknowledge 


each transmission). 


Requires more 
planning, source and 
destination must be 
selected, bandwidth 
allocation decisions 
must be made among 
sources; 2 frequencies 
required for more 
relays. 


Each endpoint must 
be selected. Relays 
can be automatically 
negotiated or 
pre-planned. Must be 
sufficient relay RSs 
available. 2 frequen- 
cies required for more 
relays. 


Increased link 
reliability. 


5 relays cover wide 
area, guaranteed 
bandwidth 
(guaranteed speed of 
service for up to 16 
sources per NL) 
and/or on-demand 
bandwidth, retains 
minimum bandwidth, 
supports one-to-one 
and few-to-many 
traffic, full bandwidth at 
5 relays. 
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(U.S. Army, 


One-to-one balanced, 
one-to-one, RS 
acknowledge, no 
contention or collision. 


Automatic relay 
negotiation by relays 
of opportunity, 
negotiated on LTS 2; 
up to 4 relays. 


Odd LTSs (3, 5, and 7) 
only. 


Very high reliability 
(RSs acknowledge 
each transmission). 


Each endpoint must 
be selected, but relays 
automatically 
negotiated. Must be 
sufficient relay RSs 
available. 





Increased link 
reliability. 


2004). 


Disadvantages 


When to Use 


When Not to 
Use 


Typical 
Application 


Resources not 
reserved so no 
immediate transmit 
guarantee. Increased 
reliability reduces 
bandwidth; no link 
reliability. 


Requirement for many 
radios to have net 
access, transmit 
unicast and/or 
multicast IP 
messages. 


Frequent requirement 
to exchange large size 
(>1MB) messages, 
require guaranteed 
bandwidth 
(guaranteed speed of 
service). 


SA network for CSMA 
short and C2 network 
for CSMA normal. 


Planning bandwidth 
can be complex, 


on-demand bandwidth 
claiming option can be 


slow; no link reliability. 


Require guaranteed 
bandwidth for limited 
number of sources, 
need extended range 
without bandwidth 
penalty, guaranteed 
speed of service. 


Many sources (radios) 


are required to access 


the network frequently 
and consistently. If 
application is not 
tolerant of slow 
bandwidth acquisition 
must use immediate 
share claim option. 


Sensor netting (e.g., 
air defense). 


Limited to 2 end 
points, equal 
bandwidth 
independent of 
endpoint data 
requirement. 


Exchange large size 
messages, require 
high reliability data 
link, require 
guaranteed bandwidth 
(guaranteed speed of 
service). 


Exchange messages 
between many-to- 
many sources. 


TOC-to-TOC large file 
transfer. 





Limited to 2 end 
points, equal 
bandwidth 
independent of 
endpoint data 
requirement. 


Require high reliability 
data link, require 
guaranteed bandwidth 
(guaranteed speed of 
service). 


Exchange messages 
between many-to- 
many sources or high 
bandwidth. 


Battle management 
data (e.g., air 
defense). 





Figure 7. Needline Comparison Chart (Cont) (U.S. Army, 
2004). 
The CCA contains a waveform mode property. The 


Waveform Mode is either 2 or 4 Ms Modes. The waveform mode 


determines how much data will be transmitted per two or 


four ms “burst.” There are 11 different types of waveform 


modes available for EPLRS networks. The waveform mode 


specifies the timing format used for over-the-air message 
transmissions. Each waveform mode offers a unique tradeoff 


of operational range, jam resistance, and data rate. AS a 


general rule the higher the waveform mode the greater the 





bandwidth available for the EPLRS network. The lower the 


mode the more resistant to jamming and more robust the 


needline. A robust needline translates into extended ranges 





for the wireless network. 
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Waveform Chart (U.S. Army, 2004). 


The data is carried over a wireless UHF frequency 
hopping RF network. The radio hops on up to 8 channels 
covering a frequency range from 420-450 MHz. The fewer 
channels utilized the less secure and greater the 
bandwidth. Each radio utilizes static routing tables to 
route traffic throughout the network. EPLRS networks are 
capable of supporting from 0 to 6 hops and 5 relays. A hop 
occurs when a packet is routed from one radio to another. 
If the receiving radio must forward the packet to another 


radio, then a relay has occurred. 


Fach EPLRS network has 8 LTSs available. An LTS is a 
Logical Time Slot. The LTS maps the traffic on the EPLRS 


radio for a specific logical network. It is possible to 
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assign a different network type to each LTS. Or assign 
several LTSs to one network. This affords the flexibility 
to split the available bandwidth between a variety of 
networks. Each network is assigned its own needline. The 
needline is a logically separate network with its own 
network IP address. The needline IP address serves as the 


default gateway for each Radio in the network. 


4. Key User Needs 
a. Poor Half-duplex Voice Communications 


Current single-channel radio communications are 





cumbersome and require extensive human-to-human protocols 


to communicate effectively. A Software-based full-duplex 





“telephone” communication application will move the 
communication protocol implementation from the user’s 


domain to the applications domain. 


b. Poor Information Exchange Quality 


Voice media communications alone often do not 
provide sufficient information to convey intent and 


exchange ideas clearly. Often commanders are required to 





relocate in order to conduct face-to-face meetings to 
convey critical information or intent. A video 
teleconferencing capability would increase the quality of 
communication and provide face-to-face communication 


without relocation. 


c. Inaccurate Telephone Directory Services 


Current Telephone Directory procedures are 
decentralized and updated frequently. As Telephone numbers 


change they make distributed directories incorrect. A real- 
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time Directory Services Manager would ensure a_e single, 


efficient, and accurate directory for users. 


d. Retransmission in Compartmentalized Terrain 


Current voice systems are line-of-site radio 





systems and require frequent retransmission to communicate 
in urban and jungle environments. A networked based 


communications tool, with automatic routing capability 





would alleviate the retransmission requirement in all but 


the most austere of networks. 


5. VoIPNET Alternatives 
a. Existing Open-Source SoftPhone 


Open-Source SoftPhone are free and currently at a 
state of functional development that would meet and exceed 
the needs of the user. However, they all provide many 
addition complex features that are not desired by the user. 


Products include: SipXezPhone, Gizmo Project, and IaxComm. 


b. Commercial Off-the-Shelf (COTS) 


COTS provide a comparable solution to open-— 
source, but at additional cost. Products include: Avaya IP 
SoftPhone, Cisco IPSoftPhone, ExpressTalk, Pingtel SIP 


SoftPhone, and Vonage SoftPhone. 


Cc. PROPOSED SOLUTION 


Section C provides a high-level view of application 
capabilities, application interfaces, and system 


configurations. 
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1. Application Perspective 


The VoIPNET application is a stand-alone VoIP 
application developed to increase the quality of 
communications for lower echelons of command. It is a low- 


cost simple alternative to expensive COTS products. In 





addition, it eliminates excessive and unnecessary features 


found in both open-source and COTS products. 


2. Application Position Statement 





U.S. Military Maneuver Elements need portable software 
based networked communication tools. VoIPNET will increase 
the quality of communication at lower echelons of command. 
Unlike COTS products and current Open-source options 
VoIPNET will provide a standard set of reliable 
communications tools at minimum cost without unneeded 


features. 


3. Assumptions and Dependencies 





VoIPNET will be developed for Windows platforms. The 
development target network is the Enhanced Position 


Location Radio System (EPLRS). 
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4. Application Capabilities Summary 


User Benefits Supporting Features 
Full Duplex Voice Button-Dial, Keyboard-Dial, 
Communication Redial, Mute, Speed Dial, 


Phone Configuration 
Face-to-Face Communication VTC 


Accurate Directory Directory Distribution, 

Services Directory Update 

Teleconference Capability Initiate Teleconference, 
Disconnect Teleconference, 
Accept Teleconference, Decline 
Telconference 


Message Center Capablity Message Center Configuration, 
Save Message, Delete Message, 
Check Message, Leave Message 


Ringer Selection Ringer-High, Ringer-Medium, 
Capability Ringer-Low, Ringer-Mute, 
Ringer-Flash 
File Transfer File-Tx 
Figure 9. VoIPNET Capabilities Summary. 
D. FEATURE ATTRIBUTES 


Section D will describe those feature attributes that 
will be utilized to track, prioritize, and manage the items 
proposed for implementation and development. 

1 Priority 


This field is established by the user. It establishes 





a feature hierarchy that drives development. 


Critical: Essential feature. Failure to implement 


means the application will fail to meet the user needs. All 





Critical features must be implemented in the scheduled 


release or a schedule slip will occur. 


17 


Important: A feature that is important to the 


effectiveness and/or efficiency of the application. Lack of 





inclusion will affect customer satisfaction, but will not 


delay release. 


Useful: A feature that will be used infrequently. The 
lack of inclusion in a release will not affect user 


satisfaction, and therefore will not delay release. 


2. Effort 


Effort is an estimate of work required to implement a 
particular feature. It is utilized to gauge complexity of 


feature implementation. 
Hard: McCabe complexity > 7. 
Firm: 3 < McCabe complexity < 7. 


Soft: McCabe complexity < 3. 


3. Risk 


Fach feature is evaluated on its potential impact on 
cost, schedule delays or cancellation. Risk is measured by 
its probability of occurrence and its impact on the afore 


mentioned resources and deliverables. 


HIGH/HIGH: Likely occurrence of unforeseen event and 
high impact if the event occurs. Occurrence will affect 


schedule, and or cost. 


MEDIUM/MEDIUM: Moderate likelihood of occurrence of an 
unforeseen event and a moderate impact if the event occurs. 


Occurrence may affect schedule and or cost. 


LOW/LOW: It is not likely an unforeseen event will 


occur during the implementation of a particular feature and 
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the impact of such an occurrence is minor. Occurrence will 


not adversely affect schedule or cost. 


4. Target Release 





The target release records the intended application 


version that the feature will first appear. 


5. Reason 


The reason field is used to track the user need that 





initiates any particular feature. It may include a brief 
description of a reference to a description. 
E. APPLICATION FEATURES 


Section E provides a high-level description of the 
application features. This description provides the 
application capabilities that are necessary to deliver 
benefits to the user, the basis for definition, scope 


management, and project management. 


Ls Peer-2-Peer Voice (P2P) 

P2P utilizes VoIP technology to provide the user with 
full-duplex voice communications over an existing data 
network. 

2. Video teleconferencing (VTC) 

VTC provides the user with face-to-face communications 
over an existing data network. 

33 Phonebook 


The phonebook provides a centrally managed, 


automatically distributed, accurate and reliable directory 
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of organizational names and telephone numbers over an 


existing data network. 


4. Message Center Services (VoiceMail) 





VoiceMail provides the user with a password protected 
audio message repository over an existing data network. 

5:. Conference Call (TeleCon) 

Telecon utilizes the P2P feature to provide users with 
the ability to conference call with up to 2 other users. 

6. Ringer Selection 

Ringer selection will allow the user to adjust the 
ringer settings for incoming calls. 

7. Button Dialing 

Button Dialing will allow for GUI dialing via a mouse 
or stylus input device. 

8. Keyboard Dialing 

Keyboard Dialing will allow for GUI dialing via 
keyboard input device. 

9. File Transfer (FileTx) 

File transfer will allow the user to transfer files 
over an existing data network. 

10. Speed Dial 


Speed Dial provides a user customizable one button 


dialing capability. 
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11. Re-Dial 

Redial is a one button feature that calls the last 
number dialed. 

12. Mute 

Mute prevents the distant user from hearing the voice 
of the initiating user. 
F. NON-FUNCTIONAL REQUIREMENTS 

Non-Functional Requirements address applicable 
Standards, Usability, Dependability, and Performance. 

1. Applicable Standards 


The development of the VoIPNET application must 





conform to the following applicable standards: 


1.323 
a 
[sp oa 


Video stream for transport using the real- 
time transport 
n th 


Bitstream i e Real-time Transport 
Protocol 


RTP Control protocol 
RTP Real-Time Transport 
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RVP over IP 


Media 
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H.225 Covers narrow-band visual telephone services 


H.235 Security and authentication 


H.323SET ee eee 
H.245 Negotiates channel usage and capabilities 


Series defines Supplementary Services fo 
H.450.1 H.323 


Call Transfer supplementary service fo 
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H.450.3 Bees diversion supplementary service O 


H.450.4 Call Hold supplementary service 
H.450.5 Call Park supplementary service 
H.450.6 Call Waiting supplementary service 


H.450.7 Message Waiting Indication supplementary 





H.450.2 
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Calling Party Name Presentation 


H.450.8 E : 
supplementary service 


H.450.9 Completion of Calls to Busy Subscribers 
supplementary service 


H.450.10 Call Offer supplementary service 
H.450.11 Call Intrusion supplementary service 
H.450.12 ANF-CMN supplementary service 


Manages registration, admission, status 





T.38 IP-based fax service maps 


Multipoint Communication Service Protocol 


T.125 (MCS) . 


H.225 Annex G 
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Session Description Protocol 


SIP Session Initiation Protocol 


Figure 10. Development Standards. 
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2. System Requirements 

Windows, PC Compatible Microphone, PC Compatible 
Headset, Network Connection > 100 kbps. 

3. Security Requirements 

Password Protection for login only. Traffic encryption 
provided via Tactical Networks. 
G. DOCUMENTATION REQUIREMENTS 


Section G identifies the deliverable documentation for 





the VoIPNET application. 


1.. Prototype Users Manual 

The Users Manual will detail the necessary steps to 
utilize all of the features available for each release. 

2. Installation Guide 


The Installation Guide will provide simple and easy 
installation and configuration instructions for both the 


application and data network. 


33 Version Specific Read-Me File 


The Read-Me file will highlight changes to this 
release of the application. In addition it should discuss 


any known compatibility issues with previous releases. 


H. GLOSSARY 


Effort - the amount of work required to implement 


a specific feature. 


COTS - Commercial Off the Shelf. 
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JTRS — Joint Tactical Radio System. 


Low-bandwidth Network - a data networks whose 


throughput is less than 300 Kbps. 
P2P -—- a refernece to a Peer to Peer architecture. 


SINCGARS: Single Channel Ground Air Radio Set. A 
frquency hopping encrypted radio system capable of 
transferring data at low rates. Primary readio system 


for U.S. military forces. 
SoftPhone - Software based telphone. 


Supplier [1] - The person or persons who produce a 


product for a customer. 


System - All of the hardware and software to 
include VoIPNET application, EPLRS Radio Network, VoIP 
headset, Terminal computer, and intermediate routing 


devices. 
System User —- see User. 
UA- User Agent 


User [1] - The person or persons who operate or 
interact directly with the product. The User(s) and the 


customer(s) are not the same person(s). 


User interface - physical manner in which the user 


will interact with a given application. 
VoIP -— Voice over Internet Protocol(IP). 


VoIPNET : Voice over Internet Protocol network. 








The name given the application under development. 





VTC Video teleconferencing. 
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II. SUPPLEMENTARY REQUIREMENTS SPECIFICATION 


A. INTRODUCTION 
a Purpose 


This document details the functional and non- 
functional requirements for the VoIPNet application. 
Although this document is intended as a set of 


Requirements, not a design, some technical information has 





been included with the requirements description. The 
primary audience for this document is the software 


development team members, system engineers, and the 





customer. 


2. Scope 


The VoIPNET System is comprised of a single software 
and multiple hardware subsystems. The Software sub-system 
contains the Graphic User interface, Phonebook Database, 
and network Communications tools. The Hardware subsystem 


contains the EPLRS radio system, Intelligence Operations 





Workstation, and a PC headset. This document identifies 
only the software portions of the system. Although there 


are functional references to hardware requirements and 





configurations, they will only be addressed in the high- 
level system architecture. The software will provide a 


suite of quality communications tools for maneuver element 





commanders and staff. 


33 Objectives and Success Criteria 


The objective is to develop, test and demonstrate a 


working prototype of the VoIPNET application. 
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1. Qualitative Evaluation: An iterative and exhaustive 


analysis of the requirements will be conducted to ensure 





that the delivered product features correspond to system 





and sub-system requirements. In addition, a detailed 
testing and evaluation phase will preclude subsequent 


iterations of requirements analysis to ensure that 





discovered requirements are included in subsequent design 


and development. 


2. Simulation: VoIPNET will be developed utilizing the 


NETBEANS 5.0 Integrated Development Environment (IDE). At 





each phase a workable prototype will be tested utilizing a 
simulated low-bandwidth network and an established EPLRS 


Network. 
3. Usability: 


a. A Limited User Evaluation (LUE) will be conducted 


with users to refine requirements. 





4. Definitions, Acronyms and Abbreviations 


A complete glossary of terms, definitions, acronyms, 
and abbreviations has been provided in Section I of this 


document. 


5. References 


[1] IEEE Std 830-1998 “Recommended Practice for 


Software Requirements Specifications.” 





[2] IEEE Std 1233-1998 “Guide for Developing System 


Requirements Specifications.” 
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[3] IEEE Std 1016-1998 “Recommended Practice for 


Software Design Descriptions.” 





[4] “Managing Software Requirements.” Leffingwell & 


Widrig. 
B. CURRENT SYSTEM 
1. Overview 





The current primary means of maneuver element 
communication are single-channel voice circuits. The voice 
circuits provide encrypted, half—duplex voice 
communications. Excessive protocols are required to manage 


traffic and 


Cc. PROPOSED SYSTEM 


1. Overview 


The VoIPNET application is intended to increase the 


quality of communications at the lower echelons of command. 





It will provide full-duplex voice communication, peer-to- 


peer video teleconferencing, file transfer, and “chat” 





functionality. 
2. Functional Requirements 
a. Performance Requirements 


See Vision Document Chapter I, section E 


b. Design Constraints 


See Vision Document Chapter I, section F, par 2 
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3G Nonfunctional Requirements 
a. Usability: 


Training: No additional training is required. 
Users will be able to use all features within 10 minutes of 


reading the Users Manual. 


b. Reliability: 


The VoIPNET application will have an availability 
rate of 99%. The following classifications are used to 
organize the types of failures that are prevalent in VoIP 


systems. 


Type I - Failure: Severe operational incidents 
that would definitely result in the removal and 
reinstallation of the application. These constitute "hard- 


core" failures that would require the services of a trained 





administrator to recover. Mean Time Between (MTBF)- Type I 
< 2 failures per year, Mean Time To Repair (MTTR) - Type I 


< 10 minutes (weibull.com 2007). 


Type II - Intervention: Any unplanned occurrence 





or failure of application mission that requires the user to 





manually adjust or otherwise intervene with the application 
or its output. These are "nuisance failures" that can be 
recovered by the customer, or with the aid of phone 
support. Depending on the nature of the failure mode, 
groups of the Type II failures could be upgraded to Type I 
if they exceed a predefined frequency of occurrence. 


Examples include, dropped calls, poor Voice quality, 





Message Center Errors, and incorrect connections, not 
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deemed network related. Mean Time Between (MTBF)- Type II < 
1 failure per month, Mean Time To Repair (MTTR) - Type II < 


5 minutes (weibull.com 2007). 


Type III - Event: Events will include all other 





occurrences that do not fall into either of the categories 
above. This might include events that cannot directly be 
classified as failures, but whose frequency is of 
engineering interest and would be appropriate for 
statistical analysis. Examples include failures caused by 
ancillary equipment malfunction or operator error. Mean 
Time Between (MTBF)- Type III < 1 failure per day 
(weibull.com 2007). 


c. Performance 


The application will be designed to support a 


Single user at a time. 


The application will be designed to support 


multiple accounts. 


The application will complete login process 


within 5 seconds. 
Dial-—Center Requirements 


The application will initiate a dial tone within 


2 seconds of the user taking the phone off-hook. 


The application will initiate a call within 1 


second after the user initiates the dial sequence. 


The application will initiate a ring tone within 


4 seconds after the user initiates the dial sequence. 


The application will terminate a connection 


within 1 second of the user selecting the “Hang-up” Button. 
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The application will open the VTC window within 


one second of the user selecting the “VTC” button. 





The application will initiate a call within 2 


seconds of the user selecting the “REDIAL” button. 





The application will mute a call with 1 second of 





the user selecting the “MUTE” button. 


The application will open the Conference call 





window within one second after the user selecting the 


“TELECON” button. 
Message Center 


The application will initiate the “Check Messages 





Greeting” within 2 seconds of the user selecting the “Check 





Messages Button.” 


The application will open the message list 





window/table within 2 seconds of the user selecting the 


“Check Message Button. 





The application will play the current message 





within 5 seconds of the user selecting the “PLAY” button. 


The application will delete the current message 





within 3 seconds of the user selecting the “DELETE” button. 


The application will save the current message 


within 3 seconds of the user selecting the “SAVE” button. 





The application will initiate the dial sequence 
for the current message within 2 seconds of the user 


selecting the “RETURN CALL” button. 
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Directory Requirements 


The application will open the Directory window 


within 2 seconds of the user selecting the “DIRECTORY” 





button. 


The application will complete the Directory 





search within 5 seconds of the user selecting the “SEARCH” 


button. 


The application will switch the tabular view of 


the directory within 1 second of the user selecting the “A, 





ByyGypad;: ly 273.7 “tabs 


The application will initiate the dialing 


sequence of the selected Directory entry within 2 seconds 





of the user selecting a directory entry. 
VTC Requirements 


The application will open the VTC window within 


one second after the user selecting the “VTC” button. 





The application will open the directory window 





within 3 seconds of the user selecting the “INVITE” button. 


The application will complete the VIC Invite 





sequence within 3 seconds of the user selecting the 


directory entry. 


The application will terminate all unanswered VTC 


invites within 10 seconds. 


The application will close the current VTC 





connection within 2 seconds of the user selecting the “END 


VIC” button. 
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Teleconference Requirements 


The application will open the Conference call 





window within one second after the user selecting the 


“TELECON” button. 


The application will open the directory window 





within 3 seconds of the user selecting the “INVITE” button. 





The application will complete the Telecon Invite 





sequence within 3 seconds of the user selecting the 


directory entry. 


The application will terminate all unanswered 


Telecon invites within 10 seconds. 


The application will close the current 


Teleconference connection within 2 seconds of the user 





selecting the “LEAVE TELECON” button. 


d. Supportability 
The application will require less than 1MB of 


system memory. 


The application will run on any platform that 


includes Java Virtual Machine. 


e. Implementation 
The application is intended to be installed on 
IOW’s currently deployed, via network download and/or disk 


installation. 


f. Interface 





The Interface requirements document the Human 


Computer Interaction (HCI) features of the VoIPNET 
application. Initial usability requirements include the 
following: 
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User Interface: this is the basic Graphical User 


Interface (GUI) it will integrate the core functional areas 





of software into a single large button screen with limited 


windows. 


Message Center Interface: this is a component of 
the GUI and provides a multi-button interface for the user 


to manage their message mailbox. 





VTC Interface: Pop-up window component of the 


GUI. This window will include all of the VTC operations. 


Telephone Book Interface: this component will 





mimic in appearance a standard telephone directory. It will 
include an alphabetic tabular representation as well as a 


search function. 


Admin Mode: this mode of operation will allow a 





VoIPNET administrator to update the Telephone directory and 


set preemption priorities for critical users. 
The application will utilize PC clock. 
The application will interface with the PC file 
system. 
4. System Models 


Section 4 elaborates the operational expectations of 
the VoIPNET application. This section is the heart of the 
requirements document and should be used drive the 


development lifecycle. 


a. Scenarios 


The user will open the VoIPNET application and 


will be prompted to login. The GUI will open and the user 
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will be prompted to set ring tone and light level (default 
is FLASH and Silent (low/red)). The user will then utilize 
the application to make and receive calls, initiate VTC 
meetings, initiate and join conference calls and search the 


directory for contact information. 


b. Use Case Models 
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VoIPNET 


«extends» 







Recieve Call 


xextends» 


pS 


Conference 
Invitation 
«extends» 


LR 





Telecon Invite 





us\) 





File Transfer 


Check Message 


Leave Message 


«extends» 







Delete Message 


Next Message 





Use Message Center 


Conference 
Termination 















Telecon Accept 


«extends» (We net 






Conference 
Invitation Response 


x 


extends» 
Conference Decline 





Configure User 
Settings 


Queury Directory 


Update Directory 














Figure 11. 





Use Case Model 
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Use case: UC-1 Phone Conversation 

Primary Actor: Userl 

Other Actors: Data Network, User2 

Description: User engages in a phone conversation 











Stakeholders and Interest: 





User wants a quick connection and a clear, error free 
conversation. 


Entry conditions: 





e Application is running. 

e Network is up and stable. 

e User logged in 

e User not engaged in any other conversation or user has 


placed current call on hold to establish a 
teleconference. 





Exit conditions: 





e Either User terminates the call. 
e System displays Main Menu. 


Flow of events: 





1. If Userl initiates a call 
a. Use UC-la User Initiates Call 
If Userl receives a call 
a. Use UC-1b User Receives Call 
IF Userl terminates a call 
a. Use UC-lc User Terminates Call 





Alternate Flows: 





la. Userl terminates the call before a connection is 
established. 


Special Requirements: 





None. 


Use case: UC-la Initiate Call 
Primary Actor: Userl 
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Other Actors: Data Network, User2 
Description: Sub-use Case of UC-1 Phone Conversation. 





Stakeholders and Interest: 





User wants an intuitive easy to use interface with the 
Dialing mechanisms. 


Entry conditions: 





e Application is running. 
e Network is up and stable. 


e User not engaged in any other conversation or user has 
placed current call on hold to establish a 
teleconference. 





Exit conditions: 





e User “clears” the number or User “Dials” the number. 
e Connection made or request terminated. 
e System displays Main Menu. 


Flow of events: 





1. Userl enters number via keypad. 

2. Userl “dials” the number. 

3. The application plays the ring-back tone (RBT). 
4. User2 answers call. 

5. The application terminates the RBT. 


Alternate Flows: 





la. If Userl selects Directory to search for a number. 

a. Use UC-6 Query Directory. 
lb. Userl selects “Speed Dial” preset button. 

a. Use UC-1la.1 Speed Dial 
lc. If User initiates “re-dial” function. 

a. Use UC-la.2 Redial 
3a. Userl terminates the call before a connection is 
established. 
3b. User2 number not in service. Application plays 
“Number Not in Service” Message. 
4c. User2 is “busy,” the application directs Userl to 
User2 mailbox. Use Leave Message UC. 
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Special Requirements: 
None. 


Use case: UC-la.1 Speed Dial 

Primary Actor: Userl 

Other Actors: Data Network, User2 

Description: Sub-use Case of UC-la Initiate Call. 











Stakeholders and Interest: 





User wants an intuitive easy to use interface with the 
Dialing mechanisms. 


Entry conditions: 





e Application is running. 
e Network is up and stable. 


e User not engaged in any other conversation or user has 
placed current call on hold to establish a 
teleconference. 





Exit conditions: 





e User “clears” the number or User “Dials” the number. 
e Connection made or request terminated. 
e System displays Main Menu. 


Flow of events: 





1. Userl selects speed dial number to call. 
2. Application places the number in the Dial Center 
Dialog Box. 


Alternate Flows: 





None. 


Special Requirements: 





None. 


Use case: UC-la.2 Redial 
Primary Actor: Userl 
Other Actors: Data Network, User2 
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Description: Sub-use Case of UC-la Initiate Call. 


Stakeholders and Interest: 





User wants an intuitive easy to use interface with the 
Dialing mechanisms. 


Entry conditions: 





e Application is running. 
e Network is up and stable. 


e User not engaged in any other conversation or user has 
placed current call on hold to establish a 
teleconference. 





Exit conditions: 





e User “clears” the number or User “Dials” the number. 
e Connection made or request terminated. 
e System displays Main Menu. 


Flow of events: 





1. The user selects “re-dial” function. 
2. Last number called is placed in the Dial Center Dialog 
Box. 





Alternate Flows: 





None. 


Special Requirements: 





None. 


Use case: UC-la.3 Abort Dial 

Primary Actor: Userl 

Other Actors: Data Network, User2 

Description: Sub-use Case of UC-la Initiate Call. 











Stakeholders and Interest: 





User wants an intuitive easy to use interface with the 
Dialing mechanisms. 
Entry conditions: 
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e Application is running. 
e Network is up and stable. 


e User not engaged in any other conversation or user has 
placed current call on hold to establish a 
teleconference. 





Exit conditions: 





e Connection request terminated. 
e System displays Main Menu. 


Flow of events: 





1. Userl hangs up the call. 
2. The application terminates the call. 


Alternate Flows: 





None. 


Special Requirements: 





A call must have been initiated. 


Use case: UC-1lb User Receives Call 
Primary Actor: User2 
Other Actors: Data Network, Userl 








Stakeholders and Interest: 





User2 wants an intuitive easy to use interface with the 
Dialing Center mechanisms. 


Entry conditions: 





e Application is running. 
e Network is up and stable. 


e User not engaged in any other conversation or user has 
placed current call on hold to establish a 
teleconference. 


e User2 has initiated a call to Userl. 





Exit conditions: 





e Connection made or request terminated. 
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e System displays Main Menu. 


Flow of events: 





1. Application generates a ring tone for Userl. 
2. Userl answers the call. 
3. Userl conducts UC-1 Phone Conversation 


Alternate Flows: 





la. Silent mode is set so a Flashing screen signals the 
incoming call. 
2a. Userl is directed to User2 Mailbox. 


Special Requirements: 





None. 


Use case: UC-lc User Terminates Call 
Primary Actor: User 
Other Actors: Data Network 








Stakeholders and Interest: 





User wants a quick and simple way to terminate a call. 


Entry conditions: 





e Application is running. 
e Network is up and stable. 
e User engaged in a phone conversation. 


Exit conditions: 





e Connection terminated. 
e System displays Main Menu. 


Flow of events: 





1. User terminates the connection. 


Alternate Flows: 





None. 
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Special Requirements: 
None. 
Use case: UC-1d Mute 


Primary Actor: User 
Other Actors: Data Network 








Stakeholders and Interest: 





User wants a quick and simple way to mute a call. 


Entry conditions: 





e Application is running. 
e Network is up and stable. 
e User engaged in a phone conversation. 


Exit conditions: 





e Mute is terminated. 
e System displays Main Menu. 


Flow of events: 
1. User selects “Mute” function 
2. Application mutes voice transmission. 
3. User selects “Un-mute” function. 
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. Application un-mutes voice transmission. 


Alternate Flows: 





None. 


Special Requirements: 





None. 


Use case: UC-le Hold 
Primary Actor: Userl 
Other Actors: Data Network, User2 








Stakeholders and Interest: 


User wants a quick and simple way to place a call on hold. 
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Entry conditions: 


e Application is running. 
e Network is up and stable. 
e User engaged in a phone conversation. 


Exit conditions: 





e Hold is terminated. 
e System displays Main Menu. 


Flow of events: 





1. User selects “Hold” function 

2. Application places connection in “hold status.” 
3. User selects “Un-hold” function. 

4. Application removes call from hold status. 


Alternate Flows: 





None. 


Special Requirements: 





None. 





Use case: UC-2 User Creates a Conference Invitation 
Primary Actor: Userl 
Other Actors: Data Network, User2 








Stakeholders and Interest: 





User wants an intuitive easy to use interface with the 
Conference Center Mechanism. 





Entry conditions: 





e Application is running. 

e Network is up and stable. 

e Userl is in a phone conversation with User2. 
e Userl has placed User2 call on hold. 


Exit conditions: 
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e Userl rescinds the invite or User2 acknowledges 
receipt of invitation. 





e System displays Conference Center Menu. 


Flow of events: 








1. Userl opens the Conference Center window. 

2. Userl places User3 number in the Conference Center dialog 
box. Use UC-la User Initiates Call 

3. Userl sends the Conference invite to User2. 

. User2 application acknowledges receipt of invite 

5. Userl application displays "Invite Received.” 





dd 








Alternate Flows: 








3a. If Teleconference Invite use UC-2b Telecon Invite. 
If VIC invite use UC-2a VTC Invite. 
3b. Userl rescinds invite 
3c. Invite time out. User2 did not receive invite. Resend 
invite x 2. 





Special Requirements: 





1. No more than one VTC per user. 


Use case: UC-2a VTC Invite 
Primary Actor: Userl 
Other Actors: Data Network, User2 





Stakeholders and Interest: 





User wants an intuitive easy to use interface with the 
Conference Center Mechanism. 





Entry conditions: 





e Application is running. 

e Network is up and stable. 

e Userl is in a phone conversation with User2. 
e Userl has placed User2 call on hold. 


Exit conditions: 





e Userl rescinds the invite or User2 acknowledges 
receipt of invitation. 
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e System displays Conference Center Menu. 


Flow of events: 





1. Userl opens the VTC window. 
2. Userl sends the VTC invite to User2. 


Alternate Flows: 





2a. Userl rescinds invite. 


2b. Invite time out. User2 did not receive invite. 


invite x 2. 

Special Requirements: 

1. No more than one VIC per user. 
Use case: UC-2b Telecon Invite 
Primary Actor: Userl 


Other Actors: Data Network, User2 
Stakeholders and Interest: 











Resend 


User wants an intuitive easy to use interface 


with the Teleconference Center Mechanism. 





Entry conditions: 
e Application is running. 
e Network is up and stable. 
e Userl is in a phone conversation with User2. 
e Userl has placed User2 call on hold. 


Exit conditions: 





e Userl rescinds the invite or User3 acknowledges 
receipt of invitation. 





e System displays Conference Center Menu. 


Flow of events: 





1. Userl opens the Teleconference window. 
2. Userl Initiates call to User3, use UC-la 
3. Userl sends the Telecon invite to User3. 





Alternate Flows: 





2a. Userl rescinds invite. 
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2b. Invite time out. User3 did not receive invite. Resend 
invite x 2. 

2c. User3 unavailable, application displays ” Number not 
In Service” message. 





Special Requirements: 





1. No more than one VIC connection at a time per user. 


Use case: UC-3 Conference Invitation Response 

Primary Actor: User2 

Other Actors: Data Network, Userl 

Description: Handles conference invitation responses for 
both Telecon and VIC Invites. 











Stakeholders and Interest: 





User wants a quick, intuitive, easy to use interface with 
the Conference Center Mechanism. 





Entry conditions: 





e Application is running. 
e Network is up and stable. 
e Conference invitation received 


Exit conditions: 





e User has joined the Conference. 


Flow of events: 








. User application opens the Conference Center window. 

. User application displays “Conference Invite” message. 
. User accepts the Conference invite. 

. User joins the conference. 


DWN EF 


Alternate Flows: 


3a. If User accepts Telecon Invite use UC-3a Accept Telecon 
Invite. 
If User accepts VTC Invite use UC-3b Accept VTC Invite 
If User declines Telecon Invite UC-3c Decline Telecon 
Invite 
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If User declines VIC Invite use UC-3d Decline VTC 
Invite 








Special Requirements: 





1. A User may being engaged in no more than one Conference 
at a time. 





Use case: UC-3a Accept Telecon Invite 

Primary Actor: User2 

Other Actors: Data Network, Userl 

Description: Extends Conference Invitation Response 











Stakeholders and Interest: 





User wants a quick, intuitive, easy to use interface with 
the Telecon Conference Center Mechanism. 





Entry conditions: 





e Application is running. 

e Network is up and stable. 

e User2 is engaged in a call with Userl 
e Telecon invitation received 


Exit conditions: 





e User has joined the Conference. 


Flow of events: 





1. User accepts the Telecon invite. 
2. The Conference Center window is displayed. 
3. The application sends “VTC Invite Accepted” response. 








Alternate Flows: 





None. 


Special Requirements: 





1. The user may be engaged in no more than one Conference 
at a time. 


Use case: UC-3b Accept VTC Invite 
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Primary Actor: User2 
Other Actors: Data Network, Userl 
Description: Extends Conference Invitation Response 








Stakeholders and Interest: 





User wants a quick, intuitive, easy to use interface with 
the VTC Conference Center Mechanism. 





Entry conditions: 





e Application is running. 

e Network is up and stable. 

e User2 is engaged in a call with Userl 
e VTC invitation received 


Exit conditions: 





e User has joined the Conference. 


Flow of events: 





. User accepts the VTC invite. 

. The VIC Screen window is displayed. 

. The application sends “VTC Invite Accepted” response. 
. The Web Cam is activated 

. The application establishes the VTC connection. 

. User conducts VIC Conference. 





NOP WN EF 


Alternate Flows: 





None. 


Special Requirements: 





1. The user may being engaged in no more than one 
Conference at a time. 





Use case: UC-3c Decline Conference Invite 
Primary Actor: User2 

Other Actors: Data Network, Userl 

Description: Extends Conference Invitation Response 











Stakeholders and Interest: 
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User wants a quick, intuitive, easy to use interface 
the Conference Center Mechanism. 





Entry conditions: 





e Application is running. 

e Network is up and stable. 

e User2 is engaged in a call with Userl 
e Conference invitation received 


Exit conditions: 


e User2 has declined the Conference Invite. 





e Conference Center window closed. 





Flow of events: 





1. User2 declines the Telecon invite. 





with 


2. Application sends ”Conference Invite Declined” message. 








3. Application closes the Conference Center Window. 


Alternate Flows: 





None. 


Special Requirements: 





None. 


Use case: UC-4 User Terminates a Conference 
Primary Actor: User 
Other Actors: Data Network 








Stakeholders and Interest: 





User wants a quick, intuitive, easy to use mechanism 
disconnecting from a conference. 


Entry conditions: 





e Application is running. 
e Network is up and stable. 
e Conference in progress 


Exit conditions: 
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for 


e User has disconnected from the Conference. 


e Conference window is closed. 


Flow of events: 





1. User selects “terminate conference” button. 
2. The application disconnects the user from the 


connection. 


Alternate Flows: 





2a. The application terminates Teleconference. 





2b. The application terminates a VTC. 
1. VTC screen closed. 
2. Teleconference remains open. 





Special Requirements: 





None. 


Use case: UC-5 Configure Settings 
Primary Actor: User 
Other Actors: None. 








Stakeholders and Interest: 





conference 


User wants a quick, intuitive, easy to use mechanism for 


configuring the application settings. 


Entry conditions: 





e Application is running. 
e User is logged in 


Exit conditions: 





e User has configured applications settings. 


e Settings window is closed. 
e Main window is displayed. 


Flow of events: 


1. User opens the settings window. 


2. User configures the application settings 
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Alternate Flows: 
2a. User configures headset volume. 
2b. User configures ringer settings. 


2c. User configures the windows theme. 


Special Requirements: 





None. 


Use case: UC-6 Query Directory 
Primary Actor: User 
Other Actors: None. 








Stakeholders and Interest: 





User wants a quick, intuitive, easy to use mechanism for 
querying the VoIPNET Directory. 


Entry conditions: 





e Application is running. 
e Directory file downloaded from Network Manager. 
e User logged in 


Exit conditions: 





e User has queried the directory. 
e Queried number is displayed in Dial Center Dialog box. 
e Directory window is closed. 


Flow of events: 





1. User opens the Directory window. 

2. User selects alphanumeric category tab from Directory. 
3. User finds the queried entry. 
4 
5 





. User selects the entry. 
. Selected number displayed in Dial Center dialog box. 


Alternate Flows: 





Za. User initiates a text search for the user. 


Special Requirements: 
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None. 


Use case: UC-7 Update VoIPNET Directory 
Primary Actor: Admin User 
Other Actors: None. 








Stakeholders and Interest: 





Admin User wants a quick, intuitive, easy to use mechanism 
for updating the VoIPNET Directory. 


Entry conditions: 





e Application is running. 
e Directory file available. 
e Admin User logged in 


Exit conditions: 





e Admin User has updated the directory repository. 





e Update Directory window is closed. 


Flow of events: 





. Admin User opens the Update Directory window. 
. Admin User selects the new Directory file. 

. Admin User distributes the new directory. 

. Admin User closes the Update Directory window. 


Dm WN FR 


Alternate Flows: 





None. 


Special Requirements: 





None. 


Use case: UC-8 File Transfer 
Primary Actor: User 
Other Actors: User2, Data Network 








Stakeholders and Interest: 





User wants a quick, intuitive, easy to use mechanism for 
transferring files. 
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Entry conditions: 


e Application is running. 
e User logged in 
e File to be transferred is available. 


Exit conditions: 





e User has transferred the file. 





e File Center window is closed. 


Flow of events: 





. User opens the File transfer window. 

. User selects the file for transfer. 

. User sends the file transfer request. 

. Receiver accepts file transfer request. 
. User transfers the file. 

. User closes the File Transfer window. 





NOP WN EF 





Alternate Flows: 
5a. Receiver declines the file transfer request. 
1. File Transfer terminated. 
2. Application sends “File Transfer 
message. 











Special Requirements: 





None. 





Use case: UC-9 Leave a Message 
Primary Actor: Userl 
Other Actors: Data Network, User2 





Description: Sub-use Case of UC-la Initiate Call. 





Stakeholders and Interest: 





Declined” 


User wants an intuitive easy to use mechanism for leaving 


messages when a call is unable to be established. 





Entry conditions: 





e Application is running. 
e Network is up and stable. 
e A call was initiated by the user. 
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e The call was “busy.” 





e The user is prompted to leave a text message. 
e Userl not engaged in any type of connection. 


Exit conditions: 





e Message is left in the distant user mailbox. 
e System displays Main Menu. 


Flow of events: 





1. Userl chooses to “leave message.” 
2. The userl types the message. 

3. The userl sends the message. 
4 
5 











. USer2 message center saves message in the mailbox queue. 
. User2 application posts “new Message” alert icon in GUI. 





Alternate Flows: 
None. 


Special Requirements: 





None. 


Use case: UC-10 Check Messages 

Primary Actor: Userl 

Other Actors: Data Network 

Description: The user checks the mailbox for any messages 
left for them. 














Stakeholders and Interest: 


User wants an intuitive easy to use mechanism for checking 
and managing incoming messages. 


Entry conditions: 





e Application is running. 
e Network is up and stable. 
e User not engaged in any type of connection. 


Exit conditions: 


e Messages have been heard, saved, or deleted. 
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e System displays Main Menu. 


Flow of events: 





. Userl selects “check messages.” 

. Application displays the message in the text area. 
. User selects “save,” “delete,” or “next.” 

. Application removes “new messages” alert icon. 
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Alternate Flows: 





3a. User “saves” message. 
1.The message is moved to the back of the mailbox queue 
and marked as “old.” 
3b. User “deletes” message. 
2. The message is deleted and the next message is played. 
3c. User selects “next” message. 
3. The user is prompted to “save,” “replay,” or delete 
the last message. The next message is played. 











Special Requirements: 





None. 


Use case: UC-11 Login 

Primary Actor: Userl 

Other Actors: None. 

Description: User logs into application 











Stakeholders and Interest: 





User wants a standardized, familiar log in procedure 


Entry conditions: 





e Application is running. 
e ACL is installed. 


Exit conditions: 





e User logged in. 
e System displays Main Menu. 
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Flow of events: 


1. User starts 
2. Application 
3. User enters 
4. Application 
5. Application 


Alternate Flows: 





application. 

displays login screen. 

user name and password. 

verifies the account credentials. 
displays Main menu. 





3a. If the users supplies incorrect login credentials, 
the application will display the login screen again with 


error message. 


Special Requirements: 





None. 
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III. SOFTWARE RISK MANAGEMENT PLAN 


A. RISK MANAGEMENT APPROACH 
ne Overall Strategy 


This section describes the high-level approach to risk 
management for this project. Risk Management will be a 
continuous activity on this project. A Risk Identification 
session will identify potential technical and non-technical 
risks. Each identified risk will be analyzed by likelihood 
of occurrence and impact. Each Risk will then be 
categorized and prioritized. Critical risks will have a 
contingency plan and a corresponding mitigation strategy 
developed. A monthly risk review will evaluate the status 
of identified risks. In addition, newly identified risks 
will be placed in the Risk Management Cycle (Texas 


Department of Information, 2007). 


2% Roles Definition 


The Matrix below identifies key roles within the 
project. Due to the size of the project all roles will be 


performed by a single person. 


: : 
fe] fo) 
J) oy] (i) 
& 4 oH ui G Gq 
yu 0d om) (J) Pall ‘d G4 
v0@d 40 (at) oO yo Lo) 2 
0 on dG Ke] Gq AY © 
nw aye Po) Yo) dy) ¥D a 
Risk Management Activit 4 2 9 2 og 56 ao es 
g Y as a WY El Bel &S a4 Pa 
Develop and administer Risk 
P P S S S S S 7 
Management Plan 
Determine if Risk Management 
g cS S S S s S P 


Plan is ready for approval 
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Requirements 
Engineer 
Packaging 


Lead 


4 
) 
) 
S 
‘dd 
ion) 
S 
2} 


re) 

0 

0 
r 
no 
Og 
Bk 
gE 
y 
B 
& 
(a 
x 
bal 
eS 


Quality 
Control 


cl) 
4 
@ 
KA 
pe) 
MH 
{e) 
n 


Risk Management Activity 


Assign and Coordinate Risk 
Management Activities 


Approve and authorize use of 
Contingency Plans 


Identify project risks 


Risk Analysis 


Risk Prioritization 


Contingency/Mitigation Plan 
Development 


Conduct Monthly Risk Review 


Modify Risk Management Plan 


Legend 
J= joint/shared responsibility 


P= primary/lead responsibility 


S support/participatory responsibility 





Figure 12. Risk Roles Definition 
B. RISK ASSESSMENT 
1. Risk Identification 


a. Methods and Techniques 


60 


Risk identification involves determining which 
risks might affect the project and documenting the 
characteristics of the risk. Risk identification will begin 
early in the planning phase and must continue throughout 
the life of the project. The following methods will be used 


to identify possible risks: 
e Brainstorming 
e Evaluations or inputs from project stakeholders 
e Periodic reviews of project data 
e Analysis of the Work Breakdown Structure (WBS) 
e Risk Factor Checklist Templates 


The process of risk identification is assisted by 
use of risk factor tables that capture indicators of 
commonly encountered risks. Risk factor tables are included 
in section D of this chapter. Each risk factor table is 
organized by categories with cues (characteristics) to help 
identify when the factor is considered low, medium, or high 
risk for the project. Risk factor tables will be used to 
prompt initial thoughts of risks for the project. Identify 
which risk factors are relevant to the project, and rate 
their potential for exposing risk to the project (low, 


medium, or high). 


b. Project Risks 


Identify and describe the project risks that will 
be used as a basis for risk analysis. Identify specific 


risks based on the defined methods and techniques. 
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Application Prototype does not meet 
Requirements. 


Requirements Analysis does not meet 
user’s needs. 


The Application Design Specification 
does not meet the Requirements as set 
forth in the Requirements Analysis 
Document. 


The Application Development 
Documentation does not meet the user’s 
format requirements. 


The Test Plan does not test a critical 
feature. 


The Application Prototype is not ready 
on schedule. 


Testing Facility/Agency unavailable to 
support Operational Test & Evaluation. 





Application does not perform as 
expected on the target network. 


Loss of Data/Plan/Reports 


Figure 13. Project Risks 


Risk Description 


The prototype is required to 
demonstrate basic call and VTC 
functionality. The inability to test 
these features renders the prototype 
useless. 


The Requirements Analysis is critical 
and discrepancies here are costly to 
reengineer. 


The correct implementation of 
engineering solutions ensures that the 
product being built satisfies the 
User’s Requirements and needs. 


The Thesis requires a specific format 
for submission. 


The test plan must thoroughly test all 
features for each release. 


A slippage in the delivery date of the 
prototype impacts the timely execution 
of the testing. 


The EPLRS radio is an asset held at 
MCTSSA. If they are unable to support 
then the application will not be tested 
on the target network. 


When the application is tested on the 
target networks it must communicate 
clearly and efficiently. 


The loss of electronic or hard copy 
materials. 





(Texas Department of Information, 
2007). 
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2. Risk Analysis 
a. Methods and Techniques 


Describes how risks will be analyzed to establish 
the project exposure for each risk and to determine which 
risks are the most important ones to address. Risk analysis 
is the process of examining each risk to refine the risk 


description, isolate the cause, quantify the probability of 





occurrence, and determine the nature and impact of possible 
effects. The result of this process is a list of risks 
rated and prioritized according to their probability of 
occurrence, severity of impact, and relationship to other 


risk areas. 


The process of risk analysis is assisted by 


determining the risk exposure (severity). The severity of a 





risk can be determined by multiplying the probability of 
the risk (event) actually occurring by the potential 
negative impact (consequence) to the project such as to 
cost, schedule, or performance. Risk analysis is assisted 
by use of a matrix that assigns risk ratings (very low, low 
moderate, high, very high) to risks based on combining 


probability and impact scales. 


Once risks have been identified, and probability 
of occurrence and consequences assigned, the risk will be 
rated as to its severity. This facilitates ranking risks in 
priority order and deciding what level of resources to 
devote to each risk. Risk analysis is performed 
continuously throughout the life of the project as new 


risks are identified and as the profile of current risks 
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change. Risks are analyzed and reviewed monthly. The 


decision to accept or reject a risk lies with the Project 


Manager. 
Risk Risk Impact 
Probability Scale RATING 

Scale 
sil Pal Very Low 
“3 £3 Low 
Be) ge) Moderate 
gel el High 
9 “9 Very High 

Figure 14. Risk Analysis Classification. 
b. Risk Analysis and Prioritization 


The rank and risk statement are provided for each 
project risk. The project risks are ranked in priority 
order based on the methods and techniques defined for risk 
analysis. The risk statement states clearly and concisely 
the context of the risk by identifying the event or 
condition (e.9., documentation format changes after 


documents are typed) and consequence (e.g., changes could 





extend project delivery completion date). Each risk 
statement is a refinement of the risk description defined 
during risk identification. The probability of occurrence, 


impact, and severity for each risk is identified. 
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Rank 


Risk Statement 
Event 


Loss of 
Data/Plan/Reports 


Testing 
Facility/Agency 
unavailable to 
support Operational 
Test & Evaluation. 


The Application 
Prototype is not 
ready on schedule. 


Application does not 
perform as expected 
on the 100kbps 
network. 


The Application 
Design Specification 
does not meet the 
Requirements as set 
forth in the 
Requirements 
Analysis Document. 


The Application 
Development 
Documentation does 
not meet the user’s 
format requirements. 





Probability 
(P), 

Impact (I), 
Severity 
(P*T) 


Consequence P I Ss 


All documents must 
be recreated and oO 9 -45 
testing redone. 


OT&E testing will 
not be conducted. 


Testing 
delayed/cancelled.|.5 |.7 |.35 





The requirements 
analysis must be 
started over. 


The Design 

Specification 

document must be 

redone. The 2 a) .10 
Prototype must be 
reengineered. 


The document must 
be reformatted. 


65 


transfer, 


address 


Risk Statement 





The Requirements 
Analysis does not 
meet the user’s 
needs. 





The Application 
Prototype does not 
meet the 
Requirements. 


The Test Plan does 


not test a critical 


feature. 


Figure 15. 





The Requirements 
engineering 
process must be 


done again. The 
Design 
Specification 


document must be 
redone. The 
Prototype must be 
reengineered. 





The Requirements 
analysis will have 
to be done again 
and the Prototype 
re-engineered. 





The test plan must 
be updated, and 
the testing 
redone. 


Risk Analysis. 


Risk Response Actions 


Risks may be 


identified and described (such as acceptance, 
avoidance, or mitigation) for how the project 

to provide the appropriate response strategies 
the risk events based on the level 


prioritization defined. 


be included. 


actions follow: 


addressed in 


Descriptions of 


different 


identifiers have been assigned to all risks. 


these 
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risk 


Probability 


(P), 


Impact (I), 


Actions have 


Severity 
(P*T) 
Te fet | 07 
Le jsot |05 
1 |.3 |.03 
ways. Unique 


to 
of 
Only the highest ranked risk items 


response 


e Accept the risk, with no investment of effort or 
cost. This is appropriate when the cost of mitigating 


exceeds the exposure, and the exposure is acceptable. 


e Transfer the risk to someone else, or agree to share 
the risk. If a customer or partner is better able to handle 


the risk, this is probably the most effective approach. 


e Avoid the risk by funding and staffing the efforts 
to reduce the probability that the risk will become a 
problem. Such mitigation tasks might include providing 
additional staff to help develop the product, getting 
special training for members of the team, or following a 


dual development path for the whole project. 


e Mitigate the risk by funding and staffing the 
efforts to reduce the loss associated with the risk should 
it become a problem. Examples might include keeping a 
backup local area network (LAN) operational during the 


deployment of a new network. 


e Establish contingency plans for significant risks 





that cannot be mitigated or otherwise resolved. Risk 
mitigation, the work required to handle the risk, may be 
small or significant; in either case, risk mitigation and 
costs assessment activities are included in the project 
schedule. Contingency management, the additional work 
required to handle the risk, must be budgeted and planned 


if the contingency event or condition occurs. 
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Application does not perform as expected on 
ee he 100kbps EPLRS network. 


Risk 
Response 
Action 


Conduct IOT&EK and use a Network Emulator to 
test the application at 100kbps on a LAN. 


A software based network emulator can mimic 
Description |network conditions that exist on the EPLRS 
network. 


Risk Event |Loss of Data/Plan/Reports. 


Risk 
Response 
Action 


Establish a SharePoint account for all 
Development Documents and Code. Conduct 

Description |/nightly uploads or as documents/code is 
changed. Backup w/ Jump Drive and Hard drive 
storage. 
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Rie RuGnE The Application Prototype is not ready on 
schedule. 


Risk ID 


Risk 
Response Mitigate. 
Action 


Monthly reviews will be conducted to ensure 
Description |that prototype development remains on 
schedule. 


rigger /7r0ttyPe review will identify schedule 
Trigger ; 

slippages. 
Assigned To |Capt Reiche. 


icat! h 
et ede Mite The Application Prototype does not meet the 
Requirements. 


Risk ID 


Risk 
Response Mitigate. 
Action 





Monthly reviews will be conducted to ensure 
Description |that the features being implemented are 
validated/verified user requirements. 


3 
Assigned To |Capt Reiche. 


Pace see Testing Facility/Agency Unavetlspr to support 
Operational Test & Evaluation. 


Risk 
Response Mitigate. 
Action 


Description |An alternate test site will be coordinated. 
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MCTSSA Testing Coordinator has not confirmed 
Trigger test date within 2 Months of Schedule test 
commencement. 


. The R Lremen Anal i not meet the 
Risk Event = a ements alysis does 
user’s needs. 


Risk ID 


Risk 
Response Avoid. 
Action 


A review will be conducted to ensure that the 
user’s needs as outlined in the Vision 
Document are reflected in the Requirements 
Specification Document. 


Assigned To |Capt Reiche. 


The Application Design Specification does not 
Risk Event meet the Requirements as set forth in the 
Requirements Analysis Document. 


Risk 
Response 
Action 


A system Design review will be conducted as 
Description jeach feature is developed to ensure that it 
meets the requirements. 


Description 
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: The Application Development Documentation does 
Risk Event 
not meet the user’s format requirements. 


Risk 
Response Mitigate. 
Action 


The Thesis template will be utilized from the 
beginning of document development. In 

Description |addition, a draft development document will be 
submitted for review 8 weeks prior to final 
delivery. 


Trigger Format review uncovers >10 errors. 
Assigned To |Capt Reiche. 


: The Test Plan does not test a critical 
Risk Event 
feature. 


Risk 
Response Mitigate. 
Action 


. : A traceability Matrix will map user 
Description : . 
needs>Requirements>Features>Test Scenario. 
: A feature is discovered during review that a 
Trigger ‘ 
test is not developed for. 











Figure 16. Risk Response Actions. 
Cy. RISK MONITORING AND CONTROL 
1. Risk Tracking 


Describes how the project team will determine if 


effective risk management is performed throughout the life 


71 


of the project. Risk Checklists are provided as Framework 
supplemental tools in section D. The Risk Initiation 
Checklist identifies items to consider when checking if 
risk management has been established appropriately. The 
Risk Initiation Checklist will be conducted prior to the 
Risk Management Plan approval. The Risk Progress Checklist 
identifies items requiring routine consideration to ensure 
the project remains focused on risk management, and new 
risk are identified and tracked. The Risk Progress 
Checklist will be completed at each monthly review. The 
Risk Completion Checklist identifies items to consider when 
a project completes, or when a major phase completes, to 
evaluate the risk management process and results. The Risk 


Completion Checklist will be completed after each iteration 





of the Requirements, Design, Development, and Testing 
phases. 
2% Risk Reporting 
a. Risk Items 


The Risk Item Report is used to provide a status 
on each of the top 5 ranked risk items that are assigned a 


mitigation strategy. Only the highest ranked risk items for 





mitigation are included and reviewed. See section D for the 


Risk Item Template. 


b. Risk Status 


A Risk Status report template is provided as a 
Framework supplemental tool in section D. The Risk Status 
report is used to provide a status of all project risks, 
including the rank for the current reporting period, the 


rank for the previous reporting period, number of times the 
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risk is on the project status list, 


the mitigation progress. 
of the top 3 ranked risk items. 
risk items for mitigation are included and 
report provides summary information for the 


placed under a mitigation strategy as well 


have be 
strategy, 
D. 


1. 


assigned 


an 


“accept,” 


Only the 


“transfer, 


and a description of 


A status will be provided for each 


highest ranked 
reviewed. This 
risks that are 
as those that 


wn 


or “avoid” 


as well as those that require contingency plans. 


RISK MANAGEMENT SUPPLEMENTAL TOOLS 


Risk Assessment Tools 


Generic Software Project Risk Factors 
(Texas Department of Information, 


Generic Software Risk Factors 


Project Name 
Prepared By 
Date 


Version 


Risk 
Factors 


Factor ID 


Mission and Goals 


1 Project 


Fit 


to Customer 
Organization 


2 Project 


Fit 


to Provider 
Organization 


VoIPNET 


C.P. Reiche 


01/15/07 


v1.0 


Low Risk 
Cues 


directly 
supports 
customer 
organization 
mission 
and/or goals 


directly 
supports 
provider 
organization 
mission 
and/or goals 


Medium Risk 
Cues 


indirectly 
impacts one 
or more goals 
of customer 


indirectly 
impacts one 
or more goals 
of provider 


High Risk 
Cues 


does not 
support or 
relate to 
customer 
organization 
mission or 
goals 


does not 
support or 
relate to 
provider 
organization 
mission or 
goals 
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Ow 


Medium 


2007) 


High 
Not 
applicable 
Need info 
TBD 


Notes 
































o 
a q 8 
a 3 
é : lh 
> | Risk Low Risk Medium Risk | High Risk oie | tio al 8 le 
@ | Factors Cues Cues Cues § $$ \ 2/32 2 | & | notes 
3 Customer customer organization project is z 
Perception expects this is working on |mismatch with 
organization project in prior products 
to provide area not or services of 
this product expected by this 
customer organization 
4 Work Flow little or no will change significantly x 
change to some aspect changes the 
work flow or have small |work flow or 
affect on method of 
work flow organization 
Program Management 
5 Goals goals of goals of goals of x 
Conflict projects projects do projects are 
within the not conflict, |in conflict, 
program are but provide either 
supportive of |little direct |directly or 
or support indirectly 
complimentary 
to each other 
6 Resource projects projects projects x 
Conflict within the within the within the 
program share |program program often 
resources schedule need the same 
without any resources resources at 
conflict carefully to the same time 
avoid (or compete 
conflict for the same 
budget) 
7 Customer multiple multiple multiple x 
Conflict customers of customers of customers of 
the program the program the program 
have common have are trying to 
needs different drive it in 
needs, but do |very different 
not conflict directions 
8 Leadership program has program has program has no x 
active person or leader, or 
program team program 
manager who responsible manager 
coordinates for program, concept is not 
projects but unable to /in use 
spend enough 
time to lead 
effectively 
9 Program program program program x 
Manager manager has manager has manager is new 
Experience deep some to the domain 
experience in |experience in 
the domain domain, is 
able to 
leverage 
subject 
matter 
experts 
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o 
a 4 
4 g (3) ba 
° 
> | Risk Low Risk Medium Risk | High Risk oie | silo al 8 le 
@ | Factors Cues Cues Cues § £$\ 2/32 2 | & | notes 
10 |Definition of|program is program is program is not x 
the Program well-defined, |well-defined, |well-defined 
with a scope but unlikely or carries 
that is to be handled |conflicting 
manageable by |by this objectives in 
this organization the scope 
organization 
Decision Drivers 
11 |Political no particular |project has project has a x 
Influences politically- several variety of 
driven politically political 
choices being |motivated influences or 
made decisions, most decisions 
such as using |are made 
a vendor behind closed 
selected for doors 
political 
reasons, 
rather than 
qualification 
s 
12 |Convenient date for date is being |date is being x 
Date delivery has partially totally driven 
been set by driven by by need to 
reasonable need to meet meet marketing 
project marketing demo, trade 
commitment demo, trade show, or other 
process show, or mandate; 
other mandate |little 
not related consideration 
to technical of project 
estimate team estimates 
13 |Attractive technology project is project is x 
Technology selected has being done in |being done as 
been in use a sub-optimal |a way to show 
for some time |way, to a new 
leverage the technology or 
purchase or as an excuse 
development to bring a new 
of new technology 
technology into the 
organization 
14 |Short Term|project meets |project is project team x 
Solution short term focused on has been 
need without short-term explicitly 








serious 
compromise to 
long term 
outlook 





solution to a 
problem, with 
little 
understanding 
of what is 
needed in the 
long term 


directed to 
ignore the 
long term 
outlook and 
focus on 
completing the 
short term 
deliverable 
































Organization Management 
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o 
a 4 
4 g (3) ba 
° 
> | Risk Low Risk Medium Risk | High Risk oie | tio al 8 le 
& | Factors Cues Cues Cues § $$ \ 2/32 2 | & | notes 
15 |Organization /little or no some management or x 
Stability change in management organization 
management or |change or structure is 
structure reorganizatio |continually or 
expected n expected rapidly 
changing 
16 |Organization |individuals individuals many in the x 
Roles and| throughout understand organization 
Responsibilit |the their own are unsure or 
ies organization roles and unaware of who 
understand responsibilit |is responsible 
their own ies, but are for many of 
roles and unsure who is |the activities 
responsibilit |responsible of the 
ies and those |for work organization 
of others outside their 
immediate 
group 
17 |Policies and|development development no policies or x 
Standards policies and policies and standards, or 
standards are |standards are |they are ill- 
defined and in place, but |defined and 
carefully are weak or unused 
followed not carefully 
followed 
18 |Management strongly some little or no x 
Support committed to commitment, support 
success of not total 
project 
19 |Executive visible and occasional no visible x 
Involvement strong support, support; no 
support provides help |help on 
on issues unresolved 
when asked issues 
20 |Project verifiable some project no established x 
Objectives project objectives, project 
objectives, measures may objectives or 
reasonable be objectives are 
requirements questionable not measurable 
Customer/User 
21 |User users highly users play minimal or no x 
Involvement involved with /minor roles, user 
project team, |moderate involvement; 
provide impact on little user 
significant system input 
input 
22 |User users highly users have users have no x 
Experience experienced experience previous 
in similar with similar experience 
projects; projects and with similar 
have specific |have needs in |projects; 
ideas of how mind unsure of how 
needs can be needs can be 
met met 
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a | 8 
4 g (3) ba 
° 
> | Risk Low Risk Medium Risk | High Risk oie | tio al 8 le 
@ | Factors Cues Cues Cues § $£$\ 2/32 2 | & | notes 
23 |User users accept users accept users do not x 
Acceptance concepts and most of accept any 
details of concepts and concepts or 
system; details of design details 
process is in |system; of system 
place for process in 
user place for 
approvals user 
approvals 
24 |User Training)user training |user training | requirements x 
Needs needs needs not identified 
considered; considered; or not 
training in no training addressed 
progress or yet or 
plan in place |/training plan 
is in 
development 
25 |User user user no x 
Justification |justification |justification |satisfactory 
complete, provided, justification 
accurate, complete with |for system 
sound some 
questions 
about 
applicability 
Project Parameters 
26 |Project Size |small, non- medium, large, highly x 
complex, or moderate complex, or 
easily complexity, not 
decomposed decomposable decomposable 
27 |Hardware little or no some significant x 
Constraints hardware- hardware- hardware-— 
imposed imposed imposed 
constraints constraints; constraints; 
or single several multiple 
platform platforms platforms 
28 |Reusable components components components x 
Components available and |available, identified, 
compatible but need some |need serious 
with approach | revision modification 
for use 
29 |Supplied components components components x 
Components available and |work under known to fail 
directly most in certain 
usable circumstances |cases, likely 
to be late, or 
incompatible 
with parts of 
approach 
30 |Budget Size sufficient questionable doubt ful x 
budget budget budget is 
allocated allocated sufficient 
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o 
a 4 
4 g (3) ba 
° 
> | Risk Low Risk Medium Risk | High Risk oie | tio al 8 le 
@ | Factors Cues Cues Cues § $£$\ 2/32 2 | & | notes 
31 | Budget funds some allocation in x 
Constraints allocated questions doubt or 
without about subject to 
constraints availability change without 
of funds notice 
32 |Cost Controls |well system in system lacking) x 
established, place, weak or nonexistent 
in place in areas 
33 |Delivery stable some unstable, x 
Commitment commitment uncertain fluctuating 
dates commitments commitments 
34 |Development team agrees team finds team agrees x 
Schedule that schedule |one phase of that two or 
is acceptable |the plan to more phases of 
and can be have a schedule are 
met schedule that |unlikely to be 
is too met 
aggressive 
Product Content 
35 |Requirements /little or no some change rapidly x 
Stability change expected changing or no 
expected to against agreed-upon 
approved set approved set baseline 
(baseline) 
36 |Requirements jall some some x 
Complete and|completely requirements requirements 
Clear specified and |incomplete or jonly in the 
clearly unclear head of the 
written customer 
37 |Testability product parts of most of x 
requirements product hard product hard 
easy to test, |to test, or to test, or no 
plans minimal test plans 
underway planning being made 
being done 
38 |Design well defined unclear how interfaces not x 
Difficulty interfaces; to design, or |well defined 
design well aspects of or controlled; 
understood design yet to |subject to 
be decided change 
39 |Implementatio |algorithms algorithms algorithms x 





n Difficulty 





and design 
are 
reasonable 
for this team 
to implement 





and/or design 
have elements 
somewhat 
difficult for 
this team to 
implement 


and/or design 
have 
components 
this team will 
find very 
difficult to 
implement 
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o 
; 4 
4 g Oo 
° A 
% | Risk Low Risk Medium Risk | High Risk oie | tio al 8 le 
@ | Factors Cues Cues Cues § $$ \ 2/32 2 | & | notes 
40 |System clearly some elements /|no clear plan x 
Dependencies |defined of the system |or schedule 
dependencies are well for how the 
of the understood whole system 
software and planned; will come 
effort and others are together 
other parts not yet 
of system comprehended 
(hardware, 
process 
changes, 
documentation 
BD cen) 
Deployment 
41 |Hardware mature, available, no growth x 
Resources for|growth some growth capacity, 
Deliverables (capacity in capacity inflexible 
system, 
flexible 
42 |Response or/readily fits operates operates x 
other boundaries occasionally continuously 
Performance needed; at boundaries |at boundary 
Factors analysis has levels 
been done 
43 |Customer requires requires requires major x 
Service little change |minor changes |changes to 
Impact to customer to customer customer 
service service service 
approach or 
offerings 
44 |Data little or no much data to much data to x 
Migration data to migrate, but migrate; 
Required migrate good several types 
descriptions of databases 
available of or no good 
structure and |descriptions 
use of what is 
where 
45 |Pilot pilot site pilot needs only available x 
Approach (or team) to be done pilot sites 
available and |with several are 
interested in |sites (who uncooperative 
participating |are willing) or in crisis 
or with one mode already 
who needs 
much help 
46 |External little or no some extensive x 
Hardware or/integration integration interfaces 
Software or interfaces jor interfaces | required 
Interfaces needed needed 









































Development Process 
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o 
; 4 
4 g Oo 
° A 
% | Risk Low Risk Medium Risk | High Risk oie | tio al 8 le 
@ | Factors Cues Cues Cues § $£$\ 8/32 2 | & | notes 
47 \Alternatives |analysis of analysis of analysis not x 
Analysis alternatives alternatives completed, not 
complete, all |complete, all 
considered, some alternatives 
assumptions assumptions considered, or 
verifiable questionable assumptions 
or faulty 
alternatives 
not fully 
considered 
48 |Commitment changes to changes to changes to x 
Process commitments commitments commitments 
in scope, are are made 
content, communicated without review 
schedule are to all or involvement 
reviewed and involved of the team 
approved by 
all involved 
49 |Quality QA system procedures no QA process x 
Assurance established, established, or established 
Approach followed, but not well procedures 
effective followed or 
effective 
50 |Development correct and some nonexistent x 
Documentation |available deficiencies, 
but available 
51 |Use of |development process no formal x 
Defined process in established, process used 
Engineering place, but not 
Process established, followed or 
effective, is 
followed by ineffective 
team 
52 |Early peer reviews peer reviews team expects x 
Identificatio /are are used to find all 
n of Defects |incorporated sporadically defects with 
throughout testing 
53 |Defect defect defect no process in x 
Tracking tracking tracking place to track 
defined, process defects 
consistent, defined, but 
effective inconsistentl 
y used 
54 |Change formal change | change no change x 
Control for|control control control 
Work Products |process in process in process used 
place, place, not 
followed, followed or 
effective 1S. 











ineffective 
































Development Environment 
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o 
a ag 
a 3 
0 5 Eee 
> | Risk Low Risk Medium Risk | High Risk oie | tio al 8 le 
@ | Factors Cues Cues Cues § £$\ 2/32 2 | & | notes 
55 |Physical little or no some major x 
Facilities modification modifications |modifications 
needed needed; some needed, or 
existent facilities 
nonexistent 
56 |Hardware stable, no some changes platform under x 
Platform changes under development 
expected, evolution, along with 
capacity is but software 
sufficient controlled 
57 |Tools in place, available, unvalidated, x 
Availability |documented, validated, proprietary or 
validated some major 
development development 
needed (or needed; no 
minimal documentation 
documentation 
) 
58 |Vendor complete adequate little or no 
Support support at support at support, high 
reasonable contracted cost, and/or 
price and in price, poor response 
needed time reasonable time 
frame response time 
60 |Disaster all areas some security |no security x 
Recovery following measures in measures in 
security place; place; backup 
guidelines; backups done; |lacking; 
data backed disaster disaster 
up; disaster recovery recovery not 
recovery considered, considered 
system in but 
place; procedures 
procedures lacking or 
followed not followed 
Project Management 
61 |PM Approach product and planning and weak or x 
process monitoring nonexistent 
planning and need planning and 
monitoring in |enhancement monitoring 
place 
63 |PM Experience |PM very PM has PM has no x 
experienced moderate experience 
with similar experience or |with this type 
projects has of project or 
experience is new to 
with project 
different management 
types of 
projects 
64 |PM Attitude strongly willing to do |cares very x 
committed to what it takes /little about 
success project 
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o 
a 4 
4 g (3) ba 
° 
> | Risk Low Risk Medium Risk | High Risk oie | tio al 8 le 
@ | Factors Cues Cues Cues § $$ \ 2/32 2 | & | notes 
65 |PM Authority /|has line is able to has little x 
management or |influence authority from 
official those location in 
authority elsewhere in the 
that enables the organization 
project organization, |structure and 
leadership based on little 
effectiveness |personal personal power 
relationships |to influence 
decision-— 
making and 
resources 
Technology 
76 | Technology technology some of the selected x 
Match to|planned for planned technology is 
Project project is technology is |a poor match 
good match to |not well- to the problem 
customers and |suited to the |or customer 
problem problem or 
customer 
77 |Technology good level of |some no experience x 
Experience of|experience experience with the 
Project Team |with with the technology 
technology technology 
78 |Availability |technology experts will need to x 
of Technology|/experts available acquire help 
Expertise readily elsewhere in from outside 
available organization the 
organization 
79 |Maturity of |technology technology is |technology is x 
Technology has been in well leading edge, 
use in the understood in |if not 
industry for the industry "bleeding 
quite some edge" in 
time nature 
Maintenance 
80 |Design structurally certain extremely x 
Complexity maintainable aspects difficult to 
(low difficult to maintain 
complexity maintain (high 
measured or (medium complexity) 
projected) complexity) 
81 |Support in place, missing some significant x 
Personnel experienced, areas of discipline or 
sufficient in |expertise expertise 
number missing 
82 |Vendor complete adequate little or no x 
Support support at support at support, high 
reasonable contracted cost, and/or 
price and in price, poor response 
needed time reasonable time 
frame response time 
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2. 


Risk Monitoring and Control 


RISK MANAGEMENT INITIATION CHECKLIST 


(Texas Department of Information, 2007) 





Risk Management Initiation Checklist 





Project Name 


VoIPNET 





Prepared By 


C.P. Reiche 





Date 


01/15/07 








ID 


Yes/No 


Items to be considered 





Consider these when initiating the overall process 


1 


n/a 





Has funding been allocated to support a risk management? 





2 


Y 


Have resources been assigned for risk identification? 





¥ 


Are the following organizations represented on the risk identification team? 
Project Team 

Support Groups (SQA, CM, test, documentation, training, etc.) 

Representatives from other elements of the program, if the project is part of 
a larger program 

Partner or supplier representative 

User representative 





Has time been made available for the risk identification team to perform 
their tasks? 





Have risk factors been selected for use by the identification team? Have they 
included the following? 

General risk table (or one tailored to the organization) 

Specific risk factor table for this type of project 

Lessons learned on previous projects 

Use these items when reviewing the results of risk identification 





Has relevant risk factor been rated? 





For each factor rated high, has a specific risk statement been written? 





For each specific risk statement, have the conditions and consequences to the 
project been stated? 





Have the specific risks been organized into sets that support the analysis of 
impact and the development of mitigation actions? 





10 


Y 


Have the risks been reviewed to determine which require further analysis? 





Use these items when reviewing the results of analysis of specific risks 
































1 Y Has each risk statement been assigned a probability of occurrence? 

2 Y Has each risk statement been assigned an impact if risk occurs? 

3 Y: Has the risk severity (probability x impact) been calculated for each risk 
statement? 

4 Y Have the risks been ranked in order of severity and agreed to by the team? 

5 N Have other project members and stakeholders reviewed and commented on the 
list? 

6 N Has the risk identification team reviewed and incorporated comments from 


other project members and stakeholders? 
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17 iY. With the risks as identified, should the project proceed as planned? 

Use these items when reviewing the results of planning risk handling actions 

18 Y Is there a mitigation action plan for each risk that is to be mitigated? 

19 Y For each risk to be mitigated, has an effort and/or cost been estimated for 
the mitigation action plan? 

20 Y Has a contingency plan been identified for the appropriate risks? 

21 Y Does the work breakdown structure for the project include risk management and 
mitigation actions? 

22 Y Have all the contingency plans been documented and do they include 
anticipated cost and effort? 

23 ¢ Has an agreement with management been made on when and if to authorize the 
use of a contingency plan? 











Risk Management Progress Checklist 


(Texas Department of Information, 2007) 


Risk Management Progress Checklist 





Project Name 


VoIPNET 





Prepared By 


C.P. Reiche 












































Date 1/15/07 

ID Yes/No Items to be considered 

1 Y¥ Is there a regular status review and update of key risks to assure they are 
under control? 

2 Y Is the Top Risk List reviewed and updated? (weekly, monthly, quarterly) 

3 Y Has the Top Risk List been disseminated to the appropriate people within the 
organization? 

4 Y For each scheduled risk mitigation action, is there progress in mitigating 
the risk as planned? 

5 Y For any risk exceeding defined trigger values, has the appropriate level of 
management approved the implementation of the contingency plan? 

6 Y Has any required risk status report been prepared for disseminating 
information at progress (and any other appropriate) reviews? 

7 Y Has the project schedule been undated to reflect the implementation of any 
approved risk contingency plans? 

8 Y Has the Project Team been reviewing the project for other risks that have 
appeared? 

9 ¥. Has the process to accept additional risks from project members and outside 
stakeholders been followed? 
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Risk Management Completion Checklists 


(Texas Department of Information, 2007) 





Risk Management Completion Checklist 




















Project Name VoIPNET Requirements Analysis 

Prepared By C.P. Reiche 

Date 2/15/07 

ID Yes/No Items to be considered 

1 Y Was it identified in the Project Plan when the effectiveness of a risk 


management process would be evaluated? (phase completion, periodically, 
project completed or terminated ) 





2 Y Were review session(s) organized with appropriate people invited to attend? 





3 Y Were the results of the risk management activities reviewed? The results 
should have included at least the following: 

Risks that were detected initially and successfully handled 

Risks that were detected during the project, but not identified at the start 
Problems that arose during the project, but were not detected as risks at any 
point 

Cost and effort of the risk management activities 

Cost and effort of risk mitigation activities 

Cost and effort of contingency plans that were implemented 





4 Y Did the review session identify any implementation problems from the 
participants? 





5 Y Were any lessons for future risk management processes identified? Items of 
interest should have included: 

Mitigation activities that were effective 

Contingency actions that were successful 

Changes to the ineffective mitigation activities 





6 N Were changes identified to risk factors for use in the future? Items of 
interest should have included: 

New factors to include in the appropriate risk factor table 

Factors that can be removed from the table 

Changes in the cues provided in the chart for high, medium, and low risks 





7 Y Were the results of the analysis incorporated into risk factor tables and the 
risk management process? 





8 n/a Were the results of the analysis disseminated to other projects that were 
using the risk management process at that time? 














Risk Management Completion Checklist 




















Project Name VoIPNET Design Phase 

Prepared By C.P. Reiche 

Date 3/15/07 

ID Yes/No Items to be considered 

1 Y. Was it identified in the Project Plan when the effectiveness of a risk 


management process would be evaluated? (phase completion, periodically, 
project completed or terminated ) 








2 Y Were review session(s) organized with appropriate people invited to attend? 
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Were the results of the risk management activities reviewed? The results 
should have included at least the following: 

Risks that were detected initially and successfully handled 

Risks that were detected during the project, but not identified at the start 
Problems that arose during the project, but were not detected as risks at any 
point 

Cost and effort of the risk management activities 

Cost and effort of risk mitigation activities 

Cost and effort of contingency plans that were implemented 

















4 Y Did the review session identify any implementation problems from the 
participants? 

5 ¥ Were any lessons for future risk management processes identified? Items of 
interest should have included: 
Mitigation activities that were effective 
Contingency actions that were successful 
Changes to the ineffective mitigation activities 

6 N Were changes identified to risk factors for use in the future? Items of 
interest should have included: 
New factors to include in the appropriate risk factor table 
Factors that can be removed from the table 
Changes in the cues provided in the chart for high, medium, and low risks 

7 Y Were the results of the analysis incorporated into risk factor tables and the 
risk management process? 

8 n/a Were the results of the analysis disseminated to other projects that were 





using the risk management process at that time? 








Risk Management Completion Checklist 





Project Name 


VoIPNET Prototype Development Phase 





Prepared By 


C.P. Reiche 





























Date 4/15/07 

ID Yes/No Items to be considered 

1 Ye Was it identified in the Project Plan when the effectiveness of a risk 
management process would be evaluated? (phase completion, periodically, 
project completed or terminated ) 

2 ¥ Were review session(s) organized with appropriate people invited to attend? 

3 Y Were the results of the risk management activities reviewed? The results 
should have included at least the following: 
Risks that were detected initially and successfully handled 
Risks that were detected during the project, but not identified at the start 
Problems that arose during the project, but were not detected as risks at any 
point 
Cost and effort of the risk management activities 
Cost and effort of risk mitigation activities 
Cost and effort of contingency plans that were implemented 

4 iv Did the review session identify any implementation problems from the 
participants? 

5 Y Were any lessons for future risk management processes identified? Items of 
interest should have included: 
Mitigation activities that were effective 
Contingency actions that were successful 
Changes to the ineffective mitigation activities 
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6 N Were changes identified to risk factors for use in the future? Items of 
interest should have included: 
New factors to include in the appropriate risk factor table 
Factors that can be removed from the table 
Changes in the cues provided in the chart for high, medium, and low risks 

7 Y Were the results of the analysis incorporated into risk factor tables and the 
risk management process? 

8 n/a Were the results of the analysis disseminated to other projects that were 





using the risk management process at that time? 








Risk Management Completion Checklist 





Project Name 


VoIPNET Prototype Testing Phase 





Prepared By 


C.P. Reiche 






































Date 5/20/07 

ID Yes/No Items to be considered 

1 Y Was it identified in the Project Plan when the effectiveness of a risk 
management process would be evaluated? (phase completion, periodically, 
project completed or terminated ) 

2 Y Were review session(s) organized with appropriate people invited to attend? 

3 Y Were the results of the risk management activities reviewed? The results 
should have included at least the following: 
Risks that were detected initially and successfully handled 
Risks that were detected during the project, but not identified at the start 
Problems that arose during the project, but were not detected as risks at any 
point 
Cost and effort of the risk management activities 
Cost and effort of risk mitigation activities 
Cost and effort of contingency plans that were implemented 

4 Y Did the review session identify any implementation problems from the 
participants? 

5 Y Were any lessons for future risk management processes identified? Items of 
interest should have included: 
Mitigation activities that were effective 
Contingency actions that were successful 
Changes to the ineffective mitigation activities 

6 N Were changes identified to risk factors for use in the future? Items of 
interest should have included: 
New factors to include in the appropriate risk factor table 
Factors that can be removed from the table 
Changes in the cues provided in the chart for high, medium, and low risks 

7 Y Were the results of the analysis incorporated into risk factor tables and the 
risk management process? 

8 n/a Were the results of the analysis disseminated to other projects that were 








using the risk management process at that time? 





RISK ITEM REPORTS 


(Texas Department of Information, 2007) 


Risk Mitigation Reporting 








Project Name 





VoIPNET 
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Prepared By C.P. Reiche 





Date 01/15/07 








Risk Item Description 











Risk ID 4 
Last Update 03/15/07 
Current Rank in Top 3 Risks 2 





Risk Statement Condition 


The Application Prototype is not ready on schedule. 





Risk Statement Consequence 


The IOT&E testing will be delayed or cancelled. 











Probability | 
Impact oT 
Severity 335 
Original Rank 3 





Current Mitigation Plan 


Monthly Prototype reviews. 











Plan Owner C.P. Reiche 
Date Mitigation Started 02/15/07 
Date to Complete Mitigation 03/18/07 
Mitigation Plan Status Completed. 





Trigger and Value for Contingency 
Plan 


Prototype Development started. 





Contingency Plan 


Conduct monthly reviews 
prototype as required. 


of Prototype 


progress. 


Re-scope 


















































Revision History v1.0 
Point of Contact C.P. Reiche 
Date Closed 03/15/07 
Risk Mitigation Reporting 

Project Name VoIPNET 

Prepared By C.P. Reiche 

Date 01/15/07 

Risk Item Description 

Risk ID 2 

Last Update 03/15/07 
Current Rank in Top 3 Risks z 





Risk Statement Condition 


Loss of Data/Plans/Reports 





Risk Statement Consequence 


All documents must be recreated and testing redone. 








Probability 





5 
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Impact 9 
Severity 45 
Original Rank 1. 





Current Mitigation Plan 


Offsite storage and nightly builds. 











Plan Owner C.P. Reiche 
Date Mitigation Started 01/15/07 
Date to Complete Mitigation 06/18/07 





Mitigation Plan Status 


Trigger and Value for Contingency 
Plan 


SharePoint account established. Jump Drive used for working 
Documents. Hard Drive local storage. 


Requirements Analysis started. 















































Contingency Plan All working documents and code are kept on a USB portable 
hard drive. Nightly uploads to the SharePoint of site 
storage. Semi-Daily uploads are made to a Local Hard drive. 

Revision History v1.0 

Point of Contact C.P. Reiche 

Date Closed 04/15/07 

Risk Mitigation Reporting 

Project Name VoIPNET 

Prepared By C.P. Reiche 

Date 01/15/07 

Risk Item Description 

Risk ID 1 

Last Update 03/15/07 

Current Rank in Top 3 Risks 2 





Risk Statement Condition 


Testing Facility/Agency unavailable to support Operational 


Test & Evaluation. 





Risk Statement Consequence 


Testing will be delayed or cancelled. 























Probability “ae 

Impact 27 

Severity £35 

Original Rank 1 

Current Mitigation Plan Purchase of network emulator to mimic 100kbps network 
environment. Coordination of alternate test site. 

Plan Owner C.P. Reiche 

Date Mitigation Started 03/15/07 

Date to Complete Mitigation 04/18/07 








Mitigation Plan Status 





Network Emulator software on order. return call 


from alternate test site. 


Pending 
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Trigger and Value for Contingenc ‘ ; 
+99 i woe. ¥ First date slide from Testing agency. 

Plan 

Contingency Plan Purchase network emulator to do 100Kbps testing. Contact 
I&I center in San Jose, CA to coordinate an alternate test 
site. 

Revision History v1.0 

Point of Contact C.P. Reiche 

Date Closed 04/15/07 








Risk Status Report 
(Texas Department of Information, 2007) 





Risk Status Report 



































Project Name VoIPNET 
Prepared By C.P. Reiche 
Date 04/23/07 
Risk Statement Rank Rank # ae : 
4 4 Mitigation 
Rank This Last Times Progress 
Condition Consequence Time Time on List 
Application does Project Failure. 
not perform as 
2 I 
2 expected on the a Ms PEOgress 
100kbps network. 
Loss of Project Failure. All 
2 Data/Plan/Reports Documentation must be 3 3 6 Completed 
recreated. Data lost. 
The Application Testing 
3 Prototype is not delayed/cancelled. 1 1 4 In progress 
ready on schedule. 
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IV. SOFTWARE DESIGN SPECIFICATIONS 


A. INTRODUCTION 
a Purpose 


The purpose of this design document in this first 
iteration is to provide sufficient documentation to produce 
a working prototype and test it against the system 


requirements document 


2. Application Scope 


The intended functionality of VoIPNET is defined in 


Section II. The scope of the first iteration prototype is 











to model the interface and make a simple User Agent (UA)- 
to- UA call. 

3. Definitions, Acronyms, and Abbreviations 

An updated copy of definitions, acronyms, and 
abbreviations are maintained in Section I. paragraph h. 

4. References 
[1] “VoIPNET Project Proposal.” Reiche. 
[2] “VoIPNET Requirements Specification Section I.” Reiche. 


[3] “Software Design: From Programming to Architecture.” 


Braude. 


[4] “MJSip Mini-Tutorial version 0.1..” Veltri. 


5. VoIPNET Design Specification Overview 


This section provides detailed technical data, system 





information, and other relevant information to VoIPNET’s 
development. This document includes an architecture 
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diagram, a design class diagram, interaction diagrams, 


state diagrams, operation contracts and a Domain Model. 


B. SYSTEM ARCHITECTURE 


VoIPNET is organized into a 3-tier closed architecture 
composed of a presentation layer, logic layer and a 
services layer. This organization is intended to provide 
modularity and minimal manipulation of code should updates 


be required. 


92 


GuiEventManager 


ConnectionManager MessageManager 
DirectoryManager StateMachine 


Figure 17. VoIPNET Architecture 





1. Architecture Subsystems 


The presentation layer is represented by the common 
graphical user interface (GUI) the GuiEventHandler class, 


The Logic layer is composed of the ConnectionManager, 


MessageManager, and DirectoryManager classes. The Services 
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Layer is composed of the MJSip, Unit, Directory, Conference 


and Message classes. 


a. Presentation Layer 


The GuiEventHandler class is one frame with an 





array of content panes for VTC viewing, message center 
operations, dial center functionality and directory 
services. GuiEventHandler calls the appropriate logic 


class when an event is detected. 


b. Logic Layer 


The Logic Layer provides the appropriate 
functionality for each GuiEventHandler event. Each event 
calls the appropriate logic Class, which in turns invokes 
the required services to perform specific tasks or 


functions. 


The ConnectionManager class initiates and 


receives voice calls from or to other UA’s. It calls the 





appropriate service level classes to initiate, terminate, 


and conduct a call. It also receives requests from both 





Service and Presentation Layers. It calls the appropriate 


service level classes in response to UA’s' conference 





invitation or conference invitation response. In addition, 
the ConnectionManager Class communicates with the 
Presentation Layer to activate the appropriate graphical 


interface for VIC or Telecon calls. 


The MessageManager class utilizes the appropriate 





service level classes to create, save and delete a text 


message for UA’s. 
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The DirectoryManager class receives requests from 
both the Presentation and Service Layers in response to 
directory queries. The class passes directory information 


to the Presentation Layer for graphical presentation. In 





addition, it creates, deletes, and updates Unit information 


in the Common Distributed Directory. 


c. Service Layer 





The service layer is the heart of the 
application. It contains several classes that provide 


functionality to the Logic Layer classes. 


The MJSip Package is a combined API and _ SIP 
protocol stack implementation (Veltri 2005). It is a four- 
tier architecture that provides Call, Dialog, Transaction, 


and Transport services/management. 





MjSip APIs 








Figure 18. MJSip Architecture (Veltri 2005). 


The Transport layer is the lowest layer in the 
MJSip stack. The SipProvider is the MJSip Object that 
provides the transport service to all upper and lower 
layers. It is also responsible for the de-multiplexing and 
direction of all incoming messages toward the appropriate 


upper layer entity. All SIP elements must use the 
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SipProvider’s API if they require access to the MJSip 


transport service (Veltri 2005). 


The second layer is the Transaction layer. In SIP 
a transaction is a request sent by a client (a transaction 
client) to a transaction server along with all responses to 
that request sent from the transaction server back to the 
client. The transaction layer handles upper-layer 
retransmissions, matching of responses to requests, and 


timeouts. The Transaction layer sends and receives messages 





through the transport layer (Veltri 2005). 


In SIP any task that a user agent client (UAC) 
accomplishes takes place using a series of transactions. As 
already introduced, the transaction layer has a client 
component (referred to as a transaction client) and a 
server component (referred to as a transaction server), 
each of which are constructed to process a particular 


request. There are two kinds of transactions: 
two-way transactions, and three-way transactions 


The third layer (above the transaction layer) is 
the Dialog layer that binds different transactions within 
the same “session.” A dialog is a peer-to-peer SIP 
relationship between two user agents that persists for some 


time. The dialog facilitates sequencing of messages and 








proper routing of requests between the user agents (Veltri 


2005). 


The upper SIP-layer is the Call Control layer and 
it implements a complete SIP call. The Call Control layer 
is implemented via the Call API. The Call API offers a 


simple-to-use interface for handling incoming and outgoing 
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SIP calls. The MJSip APIs for the four layers are 





implemented respectively by: 
- class Call (and class ExtendedCall) 
-— class InviteDialog 


- classes ClientTransaction, ServerTransaction, 


InviteClientTransaction, and InviteServerTransaction 
- class SipProvider 


The Unit class is a fundamental object that 
contains Directory information for each unit. It contains 
information regarding name, IP address, and telephone 


number. 





The Message class is a fundamental object 
containing the message contents. It is created by and 
passes its contents to the Logic layer (MessageManager 


class). 


The Conference class is the abstract class for 


the creation and management of the conference 





functionality. The class opens and closes required media 
streams and makes appropriate updates to the 


GuiEventHandler and StateMachine. 


Cc. OBJECT / CLASS DESCRIPTION 


Figure 12 shows the VoIPNET Domain Model. It 
illustrates the basic context in which the VoIPNET system 
operates. The user can initiate and receive calls, VITIC’s 


and Teleconferences via the GUI. The user also has the 





ability to search the directory for Unit information and 





leave messages for unreachable UA’s. The admin user has the 


ability to update and distribute the Directory file. 
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User GuiEventHandler 
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toUnit contact 
password 
fromUnit sdp 
message 
Figure 19. VoIPNET Domain Model. 
Lis GuiEventHandler Class Description 


The GuiEventHandler class is the user interface class 


located in the presentation layer. Its main function is to 





provide the user with the correct interface when options 


are selected. 


a. Attribute Descriptions 


JPanel[]: phoneCenterPanel 


Holds the dialing text fields and buttons. 
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Image[]: statusIcon 
A flashing icon that alerts the user when a call, 


Telecon, or VTC is in progress. 


JButton[]: JButtonO, JButtonl1..JButton9, JButton#, JButton* 
Phone dialing buttons for manual input of Telephone 


Numbers. 


JButton[]: dialButton 

Establishes a connection by searching the directory by 
Telephone number and initiates a call to the corresponding 
IP address of the user. Used for telephone number search 


only! 


JButton[]: redialButton 
Sends a message to the Connection Manager to redial 


the last number called. 


JButton[]: muteButton 
Sends a message to the system to “Mute” the 


microphone. 


JButton[]: volumeButton 


Sends a message to the system to adjust the 





earpiece/speaker volume. 


JButton[]: phoneBookUpdateButton 

Compares the timestamp of the current Directory 
with the Timestamp of other Directories on the network. If 
the current directory is older it requests an update from 


that UA. 
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JField[]: NumField 
Telephone input text field. Number buttons pushed will 
place digit text into this field. 


JPanel[]: messageCenterPanel 


Contains the message center buttons and text fields. 





JField[]: fromfield 
Contains the logged in user’s user name when a message 


is sent from the message center. 





JLabel[]: fromLabel 


Labels the “From” JField. 


JField[]: tofield 


Contains the logged in user’s user name when a message 





is sent from the message center. 


JLabel[]: toLabel 


Labels the “To” JField. 


JButton[]: checkMessageButton 


Checks the Message Center for messages left for the 








user whom is currently logged in. 


JButton[]: leaveMessageButton 
Places the logged in user name into the “From” field 


and activates the message text area. 





JButton[]: deleteButton 
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Deletes the current message from the Message Center 


Mailbox. 


JButton[]: saveButton 





Saves the message to the back of the logged in user’s 


mailbox queue. 


JButton[]: sendButton 
If the distant UA is “Busy” it posts the message into 
the mailbox of the “To” UA. If the distant UA is 





“unreachable” then the message is added to the “retransmit 


queue,” and resent to the user based on message priority. 


JButton[]: nextButton 


Advances the current message to the next message in 





the user’s message center mailbox queue. 





JCheckbox []: highPriority 


Sets priority for message retransmission attempts to 


240 at a one (1) minute interval. 
JCheckbox[]: lowPriority 


Sets priority for message retransmission attempts to 


24 at a ten (10) minute interval. 
JCheckbox[]: medPriority 


Sets priority for message retransmission attempts to 


48 at a five (5) minute interval. 
JTextArea[]: messageTextArea 
Text area for message. 


JPanel[]: unitDirectoryPanel 
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Contains the table with the Directory information. 
JTable[]: unitDirectoryTable 


Contains the directory fields, Unit Name, PhoneNumber, 
and IP address. It is scrollable and selecting an entry 


initiates the dialing sequence for that unit. 
JPanel[]: searchPanel 

Contains the search text field and search button. 
JField[]: searchField 

Text box for entering unit name to search for. 
JButton[]: searchButton 


Executes the search on the searchField entry. On 
success it highlights the entry in the directory. User is 


notified of failure. 
JPanel[]: VTCPanel 


Contains the VvTCDisplay, VTCConnectButton, and the 


VTCDisconnectButton. 
JFrame[]: VTCDisplay 


Displays the video for the VTC else displays the Unit 


crest of the current call. 
JButton[]: VTCConnectButton 


Sends a “VTC Connect” message and the current call IP 
address to the Conference Manager to initiate a VIC invite 


to the current call. 
JButton[]: VTCDisconnectButton 


Sends a “Disconnect” message and the current call IP 


address to the Conference Manager to terminate the VIC. 
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DirectoryManager[]: d 


Instance created in GUIEventHandler to access methods 


of this class. 


TableModel[]: model 





Creates the model for the unitDirectoryTable. 
String[]: searchValue 

String value of the searchField. 
Unit[]: unit 

Basic Directory Object. 


String[]: messageTo, MessageFrom, messageText 





String values for Message Center “To, From, Message” 


fields. 
MessageManager[]: manager 


Instance created in GUIEventHandler to access methods 


of this class. 
Message[]: message 


Basic message manager object. Contains the “To, From, 


and Text attributes. 
String[]: loginName 

String representation of the user login name. Passed 
to password module. 

b. Method Descriptions 

private main(): void 

Main method of the program. 
public statusIcon(): void 
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Updates the status Icon to reflect the current state 


of the application. 
private login(): void 


Executes the authentication process for the 
application. When successful the logged-in state is updated 


in the instance of StateMachine. 
private initialize(): void 

Calls login(), creates instances of StateMachine, 
ConnectionManager, DirectoryManager and MessageManager. 

2. ConnectionManager Class Description 


The ConnectionManager class is the communications 
handler class located in the logic layer. Its function is 
to apply program logic to the application, based on 


connection service requests from the Presentation Layer. In 








addition, specific service layer requests must be evaluated 
by the ConnectionManager class’s collection of business 
rules. This class initiates, monitors, and terminates Call, 
VIC, and Telecon connections made on behalf of the 


GuiEventManager (User). 


a. Attribute Descriptions 


String: lastNumberDialed 
Stores the last number dialed for the redial function. 


String: state 
Stores the current state as retrieved from the 


StateMachine. 


b. Method Descriptions 


public void makeCall1() 
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Initiates a call on behalf of the user. It pulls 
state from the StateMachine, initiates the search for the 
corresponding IP address, updates StateMachine, initiates 


the connection, and updates the status Icon. 
public string getLastNumber () 


When re-dial is called it accesses the lastNumber 


variable and returns the number to the caller. 
public void hangup () 


Initiates the termination process on behalf of 
the user. It retrieves the State, terminates the 
call/VTC/Telecon, updates State, and updates the status 


Teon. 
public void incomingCall () 


Initiates the incoming call handling process. It 
retrieves State, assigns a call identification number, and 
returns the users intent to the caller, and updates the 


status Icon. 
private assignCal1l1ID() 


Creates a timestamp based ID number for each 


call. 


public void autoAccept () 





Routes the caller to the users Message Center 


mailbox, prompts to leave a message, terminates the call 








when the message is completed, and updates the new message 





icon. 


public void initiateConference () 
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Starts the conference invite process on behalf of 
the user. Retrieves state, if a conference is already in 


progress it throws a conference rule violation method. 





private ruleViolation () 


This method is executed when a business rule is 
violated. For example; attempting to simultaneously engage 


in more than on VTC or Teleconference or attempting to 





engage in a VTC prior to establishing a call. 
public incomingConferenceInvite () 


This method initiates the process for accepting 


or declining a conference invitation. It also retrieves 





state, executes the autoDecline method (if engaged in a 
conference), and initiates the appropriate VTC/Telecon 


invite method. 
public terminateVTC () 


Disconnects the user from an established VTC, 
WITHOUT disconnecting the call itself. Destroys the 
instance of VIC, closes the VIC multimedia window, sets the 


state to call in progress, and updates the status icon. 
public terminateTelecon () 


Disconnects the user from an established 





teleconference. Destroys the instance of Telecon, 
disconnects the call, sets the state, and updates the 


status icon. 
private autoDecline () 


Automatically declines an invitation due to a 





conference rule violation. 


public vtcInvite() 
106 


This method processes an incoming VTC invitation. 
It retrieves state, displays a JOptionDialogBox for user 
input regarding accept or decline VTC. If user accepts then 
state is set, the Local SDD is retrieved, an instance of 
Telecon is created and the user conducts the video 


teleconference. 





public teleconInvite () 





This method processes an incoming teleconference 


invitation. It retrieves state, displays a JOptionDialogBox 





for user input regarding accept or decline Telecon. If user 
accepts then state is set, the Local SDD is retrieved, an 
instance of Telecon is created, the status icon is updated 


and the user conducts the teleconference. 





3. StateMachine Class Description 


The StateMachine class is the primary tool for the 
business rules enforced in the ConnectionManager class. 
This class is composed Boolean variables for each state and 
corresponding accessor/mutator methods (set/get) for the 


state of the application. 


a. Attribute Descriptions 


private Boolean[]: shuttingDown 
Application is closing. 
private Boolean[]: establishingConnection 
Call initiation in progress. 
private Boolean[]: loggingIn 
User in process of logging in to application. 
private Boolean[]: loggedIn 
User has successfully logged in to application. 


private Boolean[]: initializing 
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Application is starting up, prior to initiation of 
logic layer classes. 
private Boolean[]: stateMachineCreated 

Logic layer class is initialized. 
private Boolean[]: ready 

Application is in listen mode and ready to initiate, 
receive calls. 
private Boolean[]: connectionFailed 

The attempted connection has failed. 
private Boolean[]: connectionEstablished 

The attempted connection has succeeded. 
private Boolean[]: establishingTelecon 

Application is creating an instance of the conference 
and opening the required multimedia streams. 
private Boolean[]: teleconInProgress 


User currently engaged in a teleconference. 





private Boolean[]: teleConFailed 





Attempt to establish a teleconference has failed. 
private Boolean[]: callTerminated 

Current call has been closed. 
private Boolean[]: msgInProgress 

Caller is leaving a message in the callee’s mailbox. 
private Boolean[]: establishingCall 

User Agent is attempting to coordinate a call with the 
callee. 
private Boolean[]: callFailed 

User Agent was unable to establish a call. 
private Boolean[]: callInProgress 

User is engaged ina call. 


private Boolean[]: establishingVTC 
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Application is in the process of creating, inviting 





and connecting a video teleconference. 


private Boolean[]: vtcInProgress 





User is engaged in a video teleconference. 
private Boolean[]: vtcFailed 
Application failed to establish the video 


teleconference. 





private Boolean[]: vtcTerminated 
User/Application has closed the current video 


teleconference. 





private Boolean[]: teleconTerminated 





User/Application has closed the current 
teleconference. 
b. Method Descriptions 


public getState(): String 
Returns the current state of the application. 
public setState(String: state) 


Sets the current state of the application. 


4. MessageManager Class Description 


The MessageManager class is the logic layer class 


responsible for the management of the message handling 





procedures. It receives messages from the GUIEventHandler, 
retrieves state from StateMachine, and 
creates/checks/deletes/saves messages to the users or 


callees mailbox. 


a. Attribute Descriptions 


private Object[]: message 


Fundamental Message class object. 
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private Object[]: unit 

Instance of Unit class. 
private Object[]: data 

Instance of DataHandler class 
private String[]: inputFrom 

Holds the name of the Unit that the message is from. 
private String[]: inputTo 

Holds the name of the Unit the message is for. 
private String[]: unitName 

Name of the unit for searching the appropriate data 
structure. 
private String[]: inputText 

Field for holding the text to be left in the message. 
private GuiEventHandler[]: g 


Instance of GUIEventHandler. 
b. Method Descriptions 


public checkMessage(): void 


Accesses the mailbox of the user and plays the first 


message in the mailbox. 
public nextMessage(): void 


Advance to and plays the next message in the users 


mailbox. 


public deleteMessage(): void 





Deletes the current message in the user’s mailbox. 
public leaveMessage(): void 


Places the “To:” and “From” information into the text 


fields and sends a message to the user’s mailbox. 


public saveMessage(): void 
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Saves the last message and places it at the end of the 


message queue in the mailbox. 





5. DirectoryManager Class Description 


The DirectoryManager class is logic layer class for 
creating, manipulating, searching, and modifying the 
directory. The Directory File I/O is handled here and 


several TreeMaps are utilized to expedite searches based on 








multiple criteria. The class receives search parameters 
from the GuiEventHandler, retrieves state from the 
StateMachine, and retrieves unit information from the 


instances of Unit. 


a. Attribute Descriptions 


private BufferedReader[]: bufReader 


For reading the contents of the fileReader. 





private File[]: inFile 

Variable for the name of the directory file. 
private FileReader[]: fileReader 

Variable for reading the inFile. 
private int[]: status 

JFileChooser input status variable. 
private int[]: count 

Counts the lines read from file into the unitArray. 
private int[]: fileSize 

Control variable for iteration while building the 
unitArray. 
private String[]: str 

Variable for storing the contents of the line from 
bufReader. 


private String[]: unitName 


Be EAE 


Variable to hold unit name and place into the 
appropriate unit object in the unitArray. 
private String[]: unitTel 

Variable to hold unit telephone number and place into 
the appropriate unit object in the unitArray. 
private String[]: unitIP 

Variable to hold unit IP address and place into the 
appropriate unit object in the unitArray. 
private String[]: dialNumber 

Holds the number/URL to be dialed by the application. 
private TableModel[]: model 

Sets the format for the display of the Directory. 
private JFrame[]: frame 

Contains the directory. 
private StringBuffer[]: document 

Assist in the opening and reading of the directory 
file. 
private Unit[]: unit 

Object created when read from the directory file and 
placed into the unit Array. 
private GuiEventHandler[]: g 

Instance of g passed to the constructor of the 
DirectoryManager to give access to presentation layer 
methods. 
private String[][]: unitArray 

Array created to hold the unit objects that are 
created from the directory file. 
private Unit[]: searchResult 


Unit object returned when a search is successful. 





private JFileChoser[]: chooser 
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Selects the directory file to open with the user 
agent. 
public TreeMap[]: dialMap 
Maps a unit telephone number to its unit name. 
public TreeMap[]: phoneNum 
Maps a unit’s name to its telephone number 
public TreeMap[]: URL 
Maps a unit’s name to its URL. 
public TreeMap[]: unitMap 
Maps a unit name to its Unit object. 
public Boolean[]: treeSet 
Tracks the status of the creation of the directory 
table and the creation of the TreeMaps. 
public Final Static String[]: HEADER 


Header for the directory table. 
b. Method Descriptions 


public open () 





Initiates the open resource method to open. the 
directory file and calls refreshList() to repaint the 


director table in the GuiEventHandler 
public openResource () 
Opens the directory file. 


public refreshList () 





Passes the model parameters for the Directory table to 


the GuiEventHandler when a directory update occurs. 
public createTree () 


Creates an unsorted array (unitArray) from the inFile 


that is opened as the directory file, creates the Unit 
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objects for each directory entry, and creates the TreeMaps 


for searches. 


public displayDirectory () 





Refreshes the directory table in the GuiEventHandler. 
public search () 


Searches the directory for the searchValue and if 


found displays the telephone number or URL in the 





numberDisplay field of the GuiEventHandler. 


6. MJSip Class Description 


The MJSip class implements the call, transaction, 


dialog, and transport services for the application. Access 





to these services is provided through the UserAgent class 
of the MJSip package. 
a. Attribute Descriptions 

Log: log 

Event logger. 
protected UserAgentProfile: user_profile 

Variable for the UserAgentProfile 
protected SipProvider sip_provider 

Variable for the SipProvider 
protected ExtendedCall: call 


Fundamental functionality is derived from this class 


instance. 
protected MediaLauncher: audio_app 


Audio application variable. 
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protected MediaLauncher: video_app 
Video application 

protected String: local_session 
Local SDP. 

protected UserAgentListener: listener 


Variable for the required instance of 


UserAgentListener. 
final String: MEDIA_PATH 
Sets the path for media needed by the User Agent. 


final String: CLIP_ON 





Appends the MEDIA Path + the file name for the on.wav 
file. 


final String CLIP_OFF 


Appends the MEDIA Path + the file name for the 


off.wav. 
final String: CLIP_RING 


Appends the MEDIA Path + the file name for _ the 


ring.wav file. 
AudioClipPlayer clip_ring 
Sets the ring sound. 
AudioClipPlayer: clip_on; 
Sets the on sound. 
AudioClipPlayer: clip_off 


Sets the off sound. 
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b. Method Descriptions 

public call(): void 

Makes a new call 
public accept(): void 

Accepts an incoming call. 
public hangUp(): void 

Closes an ongoing, incoming, or pending call. 
public getSessionDescriptor(): void 

Gets the local SDP. 
public getStatus(): void 

Returns the status of the call. 
public listen(): void 

Waits for an incoming call 
public printLog(): void 

Prints events to the log. 
public setLocalSessionDescriptor(): void 


Sets the local SDP. 


7. Unit Class Description 


The Unit class is the fundamental information object 
in the application. Each Unit object contains information 
to aid identification and communication with each 
respective unit. 


a. Attribute Descriptions 


String[]: unitName 
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The unit’s name. 
String[]: unitTel 

The unit’s telephone number. 
String[]: unitURL 

The unit’s URL. 
Boolean[]: isBusy 


LinkedList[]: messageQueue The unit’s mailbox. 


b. Method Descriptions 

public getURL(): String 

Returns the unit’s URL. 
public getMessageQueue(): LinkedList 

Returns the unit’s mailbox. 
public getName(): String 

Returns the unit’s name. 
public getStatus(): Boolean 

Returns the unit’s call status. 
public getTel(): String 

Returns the unit’s telephone number. 
public setStatus(): void 


Sets the unit’s call status. 


8. Message Class Description 


The Message class is the fundamental object of 





MessageCenter operation. It contains the addressing 
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the 


and 


content elements of each message. Each instance of Message 





is stored in the corresponding mailbox (messageQueue) 


the respective unit. 





a. Attribute Descriptions 


String[]: from 

Whom the message is from. 
String[]: to 

Whom the message is to. 
String[]: text 


Content of the message. 


b. Method Descriptions 
public getTo(): String 
Returns the contents of the To variable. 
public getFrom(): String 
Returns the contents of the "From" variable. 
public getText (): String 


Returns the contents of the text variable. 


9. Conference Class Description 
The Conference class is an abstract class for 
creation and management of user conferences. 
a. Attribute Descriptions 


String[]: conferenceID 


Unique identification number for each conference. 
String[]: sdpl 


Session Descriptor for conference participant 1 


118 


for 


the 


String[]: sdp2 
Session Descriptor for conference participant 2. 
b. Method Descriptions 
public invite(): String 
Sends an invitation to a caller on behalf of the user. 


public displayInviteMessage(): void 





Displays the invitation and solicits an accept/decline 


option. 


public terminateConference (conferenceID): void 





Terminates the requested conference. 


public cancelConference (conferencelID) : 





Cancels the conference request prior to connection. 


10. vTC Class Description 


The class extends the Conference class. It requires an 
additional multimedia stream as well as synchronization 


between the audio and video streams. 


a. Attribute Descriptions 


Boolean[]: vtcStatus 
Maintains the status of video connection. 
VICLauncher[]: media_app 
Video media object. 
b. Method Descriptions 


public cancelConference () 


Cancels the VTC and destructs the instance. 
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11. Telecon Class Description 


The Telecon class extends the Conference class. 


a. Attribute Descriptions 


None. 


b. Method Descriptions 
public leaveConference () 


Disconnects the user from the current conference, 
but does not destroy the conference object. This allows 


other connected users to remain in conference. 


D. BOUNDARY USE CASE 
Use case: UC-12 Application Startup 


Primary Actor: User 





Other Actors: VoIPNET Application 





Stakeholders and Interest: 
User wants the application to initialize quickly 
and without error. 





Entry conditions: 





e Application is installed on the hardware 


Exit conditions: 





e Application GUI is displayed 
e Application is listening for incoming call requests 


Flow of events: 





1. The application initializes. 

2. The application initializes the StateMachine class 
3. The application displays the login screen. 

4. The user logs in. 

5. The application initializes the Logic layer classes 
6. The application displays the GUI 
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Alternate Flows: 


5.a. User logs in incorrectly. 
1. Application displays login screen 


Special Requirements: 





None. 


1: initialized) 





se 2: createStateMachine() 


~ >> initializing 


Saas 
ieee 3: displayLogin() 





login displayed 





4: loging) 
>| 
7 “3o3 login Successful 
K--~ 
a 5: initLogicClasses() 
i ~ >> application ready 
e- 
a 6: displayGui() 
gui displayed 











Figure 20. VoIPNET Start up Sequence Diagram. 





Contract: C12: start 
Operation: start () 
Cross Reference: UC-12: Application Startup 


Preconditions: None. 
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Postconditions: 


1. A new instance s of StateMachine was created. 

2. A new instance g of GuiEventHandler was created and 
displayed. 

3. A new instance d of DataHandler was created. 

4. A new instance ec of ConnectionManager was created. 
5. The application ready to process calls. 
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Figure 22. VoIPNET UC-la: Initiate Call Interaction 
Diagram. 
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Figure 24. VoIPNET UC-la.2 Re-Dial Interaction Diagram. 
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UC-1a.3: Abort Connection 
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Figure 25. 
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VoIPNET UC-la.3 Abort 


Diagram. 
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Connection Interaction 
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UC-1b: Receive Call 
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Figure 26. VoIPNET UC-1b Receive Call Interaction 


Diagram. 
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UC-1c: Terminate Call 
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Figure 27. VoIPNET UC-lc Terminate Call Interaction 
Diagram. 
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Figure 28. VoIPNET UC-2 Create Conference Invitation 


Interaction Diagram. 
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UC-2a: VTC Invite 
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Figure 30. 


o 
o 





teleconInvite() 
f= 


setState(establishingTelecon) 


UC-2b: Telecon Invite 





s: StateMachine 

















getLocalSessionDescriptor() 








cal 


: call 








H 
returns local session descriptor 





t: Telecon 











createTelecon()} 





returns invite response 


> 
i invite() 


sends Invite 








cancelTelecon() 








1 
setState(teleconTerminated) 














setState(teleconInProgress) 








ituslcon(teleconInProgress) 
<——$£§£_———————_ 














Diagram. 


132 





If inviteResponse == Decline 
destruct t : Telecon 


conductTelecon(} 

















VoIPNET UC-2b Telecon Invite Interaction 
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Figure 31. VoIPNET UC-3 Conference Invitation Response 


Interaction Diagram. 
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Figure 32. 
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UC-3b: Accept VTC Invite 
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Figure 33. VoIPNET UC-3b Accept VTC Invite Interaction 


Diagram. 
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UC-3c: Decline Conference Invite 
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Figure 34. VoIPNET UC-3c Decline Conference Invite 
Interaction Diagram. 
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UC-4: Terminate Conference 
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Interaction Diagram. 
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UC-6: Query Directory 
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Figure 36. 
Interaction Diagram. 
G. OPERATIONAL CONTRACTS 
Contract: Cl makeCall(telNumber : string) 


Cross Reference: UC-la: Initiate Call 


of 


Preconditions: 
Figure 37. Application running. 
Figure 38. User logged in. 
Figure 39. An instance c 
created. 
Figure 40. 


ConnectionManager 


An instance s of StateMachine was created. 
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was 


Figure 41. An instance d of DirectoryManager was 


created. 
Figure 42. An instance dir of Directory was created. 
Figure 43. s.getState() == ready. 
Figure 44. User enters a telephone number. 
Postconditions: 


1. Application state is returned from s. 

2. ipAddress is returned from d. 

3. A new instance c of Call is created. 

4. s.getState() == calliInProgress. 

5. A call request is sent to the callee call(). 


6. g.callInProgressIcon == TRUE. 


Contract: C2 getState() : string 
Cross Reference: UC-la: Initiate Call 
Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance ec of ConnectionManager was created. 
4. An instance s of StateMachine was created. 
Postconditions: 


1. Application state is returned from s. 


Contract: C3 getIP(telNumber : string) : string 


Cross Reference: UC-la: Initiate Call 
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Preconditions: 


1. Application running. 
2. User logged in. 
3. An instance ec of ConnectionManager was created. 
4. An instance s of StateMachine was created. 
5. An instance d of DirectoryManager was created. 
6. An instance dir of Directory was created. 
7. s.getState() == ready. 
8. User enters a telephone number. 
Postconditions: 
1. ipAddress is returned from d. 
Contract: C4 getIP(telNumber : string) : string 


Cross Reference: UC-la: Initiate Call 


Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance ec of ConnectionManager was created. 
4. An instance s of StateMachine was created. 
5. An instance d of DirectoryManager was created. 
6. An instance u of Unit was created. 
7. s.getState() == ready. 
8. User enters a telephone number. 
9. d.getIP() has been called. 
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Postconditions: 


1. ipAddress is returned to d from u. 


Contract: C5 setState(state : string) 
Cross Reference: UC-la: Initiate Call 
Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance c of ConnectionManager was created. 
4. An instance s of StateMachine was created. 


5. A c event triggers a state change. 


Postconditions: 
s.getState() == this.state. 
Contract: C6 call(callee, from, contact,sdp : string) 


Cross Reference: UC-la: Initiate Call 
Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance c of ConnectionManager was created. 
4. An instance s of StateMachine was created. 
5. An instance d of DirectoryManager was created. 
6. An instance u of Unit was created. 
7. s.getState() == establishingCall. 


Postconditions: 


1. A new instance call of Call is created 
2. s.getState() == callInProgress. 


3. g.callInProgressIcon == TRUE. 


Contract: C7 speedDialButtonEvent () 
Cross Reference: UC-la.1: Speed-Dial 
Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance ec of ConnectionManager was created. 
4. An instance s of StateMachine was created. 
5. An instance d of DirectoryManager was created. 
6. An instance u of unit was created. 
7. Speed-Dial presets are configured. 
8. s.getState() == ready. 
Postconditions: 
1. Application state is returned from s. 
2. ipAddress is returned from d. 
3. A new instance call of Call is created. 
4. s.getState() == callInProgress. 
5. A call request is sent to the callee. 


6. g.callInProgressIcon == TRUE. 


Contract: C8 reDialButtonEvent () 
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Cross Reference: UC-la.2: Re-Dial 
Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance ec of ConnectionManager was created. 
4. c.lastNumDialedQue!= nil. 
5. An instance s of StateMachine was created. 
6. An instance d of DirectoryManager was created. 
7. An instance u of Unit was created. 
8. s.getState() == ready. 
Postconditions: 
1. Application state is returned from s. 
2. ipAddress is returned from d. 
3. A new instance call of Call is created. 
4. s.getState() == calliInProgress. 
5. A call request is sent to the callee. 


6. g.callInProgressIcon == TRUE. 


Contract: C9 getLastNumber() : string 
Cross Reference: UC-la.2: Re-Dial 
Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance c of ConnectionManager was created. 
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4. c.lastNumDialedQue!= nil. 
5. An instance s of StateMachine was created. 
6. An instance d of DirectoryManager was created. 
7. An instance u of unit was created. 
8. s.getState() == ready. 
Postconditions: 


1. last Number dialed is returned from Que. 


Contract: C10 hangUp() 
Cross Reference: UC-1la.3: Abort Connection 
Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance ec of ConnectionManager was created. 
4. An instance s of StateMachine was created. 
5. An instance d of DirectoryManager was created. 
6. An instance u of Unit was created. 


7. s.getState()==establishingConnection| | 


connectionEstablished||establishingCall. 
Postconditions: 
1. The call is canceled. 
2. s.getState() == callTerminated. 


3. s.getState() == ready. 
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Contract: Cll cancel () 
Cross Reference: UC-1la.3: Abort Connection 
Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance ec of ConnectionManager was created. 
4. An instance s of StateMachine was created. 
5. An instance d of DirectoryManager was created. 
6. An instance u of Unit was created. 


7. s.getState()==establishingConnection| | 


connectionEstablished || establishingCall. 
8. call.call() has been called. 
Postconditions: 
1. The call is canceled. 
2. s.getState() == callTerminated. 


3. s.getState() == ready. 


Contract: C12 listen() 
Cross Reference: UC-1b: Receive Call 
Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance ec of ConnectionManager was created. 


4. An instance s of StateMachine was created. 
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5. An instance d of DirectoryManager was created. 


6. An instance u of Unit was created. 
7. s.getState() == ready. 
Postconditions: 


1. An incoming call is identified. 


2. call.getRemoteSessionDescriptor() is called. 


Contract: C13 getRemoteSessionDescriptor () 
Cross Reference: UC-1b: Receive Call 
Preconditions: 

1. Application running. 


2. User logged in. 


3. An instance c¢ of ConnectionManager was created. 


4. An instance s of StateMachine was created. 


5. An instance d of DirectoryManager was created. 


6. An instance u of Unit was created. 

7. An instance call of Call has been created. 

8. call.listen() has been called. 

9. Incoming call has been identified. 
Postconditions: 


1. Remote Session Descriptor is retrieved 


caller. 


Contract: C14 incomingCall () 
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from 


Cross Reference: UC-1b: Receive Call 
Preconditions: 
2. Application running. 
3. User logged in. 
4. An instance ec of ConnectionManager was created. 
5. An instance s of StateMachine was created. 
6. An instance d of DirectoryManager was created. 
7. An instance u of Unit was created. 
8. An instance call of call was created 
9. An instance m of MessageManager is created. 
AHO, call.listen() has been called. 


si call.getRemoteSessionDescriptor () has been 


called. 
Postconditions: 
1. If (vtcInProgress| |teleconInProgress) 
a. Auto accept the call call.accept(). 


b. Direct caller to the callee mailbox 


m.leaveMessage (). 
c. Update state s.setState(msgInProgress) . 


d. The message is completed so call 


c.terminateCall (). 


e. Set the new message Icon 


g.NewMsgIcon (true). 
f. Assign new call ID number c.assignCallID(). 


g. Prompt accept/refuse call c.acceptCall?(). 
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2. If the call is refused call call.refuse(). 


a. Update the state by calling 


s.setState (callTerminated). 
3. If call is accepted call call.accept(). 


a. Update the state by calling 


s.setState(callInProgress) . 


Contract: C15 assignCallID(sdp : string) :string 
Cross Reference: UC-1b: Receive Call 
Preconditions: 

1. Application running. 

2. User logged in. 

3. An instance ec of ConnectionManager was created. 

4. An instance s of StateMachine was created. 

5. An instance d of DirectoryManager was created. 

6. An instance u of Unit was created. 

7. An instance call of call was created 

8. s.getState() == ready. 

9. listen.call() has been called 

10. c.incomingCall() has been called. 
Postconditions: 


1. call ID number is returned to ec 


Contract: C16 acceptCall?() 
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Cross Reference: UC-1b: Receive Call 
Preconditions: 

1. Application running. 

2. User logged in. 

3. An instance ec of ConnectionManager was created. 

4. An instance s of StateMachine was created. 

5. An instance d of DirectoryManager was created. 

6. An instance u of Unit was created. 

7. An instance call of call was created. 

8. c.incomingCall() has been called. 
Postconditions: 

1. If the call is accepted call.accept(). 

2. s.getState() == calliInProgress. 

3. If the call is refused call.refuse(). 


4. s.getState() == callTerminated. 


Contract: C17 accept () 
Cross Reference: UC-1b: Receive Call 
Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance ec of ConnectionManager was created. 
4. An instance s of StateMachine was created. 
5. An instance d of DirectoryManager was created. 
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6. An instance u of Unit was created. 

7. An instance call of call was created. 

8. s.getState() == calliInProgress. 
Postconditions: 

1. Call is accepted. 


2. The caller/callee conduct the call 
c.conductCall (). 


Contract: C18 refuse () 
Cross Reference: UC-1b: Receive Call 
Preconditions: 

1. Application running. 

2. User logged in. 

3. An instance ec of ConnectionManager was created. 

4. An instance s of StateMachine was created. 

5. An instance d of DirectoryManager was created. 

6. An instance u of Unit was created. 

7. An instance call of call was created 

8. s.getState() == establishingConnection. 

9. c.incomingCall() has been called. 
Postconditions: 

1. The call is refused. 

2. s.getState() == callTerminated. 


3. s.getState() == ready. 
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Contract: C19 leaveMessage () 
Cross Reference: UC-1b: Receive Call 
Preconditions: 
1. Application running. 
2. User logged in. 
3. An instance ec of ConnectionManager was created. 
4. An instance s of StateMachine was created. 
5. An instance d of DirectoryManager was created. 


6. An instance u of Unit for all entries in 


directory is created. 
7. An instance call of call was created. 
8. An instance m of MessageManager was created. 
9. s.getState() == msgInProgress. 
Postconditions: 
1. A new instance msg of Message is created. 


2. Unit mailbox updated with message 


u.messageQueue (msg) . 
3. s.getState() == callTerminated 


4. s.getState() == ready. 


Contract: C20 setMsgIcon() 
Cross Reference: UC-lb: Receive Call 
Preconditions: 


1. Application running. 


Lot 


2. User logged in. 
3. A new instance msg of Message is created 


4. Unit mailbox updated with message 


u.messageQueue (msg) . 


5. s.getState() == callTerminated. 
6. s.getState() == ready. 
Postconditions: 





1. The new message Icon is displayed. 


Contract: C21 bye() 
Cross Reference: UC-l1c: Terminate Call 
Preconditions: 

1. Application running. 

2. User logged in. 

3. A new instance msg of Message is created 


4. Unit mailbox updated with message 


u.messageQueue (msg) . 


5. s.getState() == callTerminated. 
6. s.getState() == ready. 
Postconditions: 





1. The new message Icon is displayed. 


Contract: C22 terminateTelecon () 


Cross Reference: UC-lc: Terminate Call 
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Preconditions: 
1. Application running. 
2. User logged in. 
3. A new instance msg of Message is created 


4. Unit mailbox updated with message 


u.messageQueue (msg) . 


5. s.getState() == callTerminated. 
6. s.getState() == ready. 
Postconditions: 





1. The new message Icon is displayed. 


Contract: C23 terminateVTC () 
Cross Reference: UC-lc: Terminate Call 
Preconditions: 

1. Application running. 

2. User logged in. 

3. A new instance msg of Message is created 


4. Unit mailbox updated with message 


u.messageQueue (msg) . 


5. s.getState() == callTerminated. 
6. s.getState() == ready. 
Postconditions: 





1. The new message Icon is displayed. 
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Contract: C24 isOnCall() 
Cross Reference: UC-lc: Terminate Call 
Preconditions: 

1. Application running. 

2. User logged in. 

3. A new instance msg of Message is created 


4. Unit mailbox updated with message 


u.messageQueue (msg) . 


5. s.getState() == callTerminated. 
6. s.getState() == ready. 
Postconditions: 





The new message Icon is displayed. 





Contract: C25 initiateConference() 
Cross Reference: UC-2a/b: VTC Invite/Telecon Invite 
Preconditions: 

1. Application running. 


2. User logged in. 


3. vtc/teleconButtonEvent() has occurred. 
Postconditions: 
1. The “VTC/Telecon Authorized” message is 
displayed. 


2. c.vtcInvite() or c.teleconInvite() is called. 


3. -or- call c.ruleViolation() and display error 


message. 
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Contract: C26 vtcInvite() 
Cross Reference: UC-2a: VTC Invite 
Preconditions: 
1. Application running. 
2. User logged in. 
3. initiateConference() has been called. 
4. s.getState() == ready. 
Postconditions: 
1. A new instance v of VTC is created createVTC(). 
2. The “Invite sent” message is displayed. 


3. The invite is sent to the callee. 


Contract: C27 createVTC(sdp) 
Cross Reference: UC-2a: VTC Invite 
Preconditions: 

1. vtcInvite() has been called. 

2. getLocalSessionDescriptor() has been called. 
Postconditions: 

1. A new instance v of VTC is created. 

2. The “Invite sent” message is displayed. 


3. The invite is sent to the invitee v.invite(). 


Contract: C28 getLocalSessionDescriptor() :sdp 
Cross Reference: UC-2a: VTC Invite 
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Preconditions: 
1. vtcInvite() has been called. 
Postconditions: 


2. The sdp is returned to ce. 


Contract: C29 v.invite() 
Cross Reference: UC-2a: VTC Invite 
Preconditions: 

1. createVtc() has been called. 
Postconditions: 


2. The invite is sent to the invitee. 


Contract: C30 teleconInvite() 
Cross Reference: UC-2b: Telecon Invite 
Preconditions: 
1. Application running. 
2. User logged in. 
3. initiateConference() has been called. 
4. s.getState (ready). 
Postconditions: 


1.A new instance t of Telecon is 


createTelecon (). 
2. The “Invite sent” message is displayed. 


3. The invite is sent to the callee. 
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created 


Contract: C31 createTelecon (sdp) 
Cross Reference: UC-2b: Telecon Invite 
Preconditions: 

1. teleconInvite() has been called. 

2. getLocalSessionDescriptor() has been called. 
Postconditions: 

1. A new instance t of Telecon is created. 

2. The “Invite sent” message is displayed. 


3. The invite is sent to the callee t.invite(). 


Contract: C32 t.invite() 
Cross Reference: UC-2b: Telecon Invite 
Preconditions: 

1. createTelecon() has been called. 
Postconditions: 


1. The invite is sent to the callee. 


Contract: C33 incomingConfInvite() :inviteResponse 
Cross Reference: UC-3: Conference Invitation Response 
Preconditions: 

1. isOnCall ()== TRUE. 

2. An invite is sent from caller. 
Postconditions: 

1. The conference display message is displayed. 


2. The invite response is sent to the caller. 
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Contract: C34 displayVTCInviteMsg () 
Cross Reference: UC-3: Conference Invitation Response 
Preconditions: 

1. incomingConfenceInvite() has been called. 
Postconditions: 

1. The “Join VTC?” message is displayed. 


2. The user accepts the invite 
c.acceptConfButtonEvent() or declines the invite 


c.declineConfButtonEvent (). 


Contract: C35 displayTeleconInviteMsg() 
Cross Reference: UC-3: Conference Invitation Response 
Preconditions: 
incomingConfenceInvite() has been called. 
Postconditions: 

1. The “Join Telecon?” message is displayed. 


2. The user accepts invite c.acceptConfButtonEvent () 
or declines the invite 


c.declineConfButtonEvent (). 


Contract: C36 autoDecline () 
Cross Reference: UC-—3: Conference Invitation Response 
Preconditions: 

1. incomingConfenceInvite() has been called. 


2. s.getState == teleconInProgress | | vtcInProgress. 
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Postconditions: 


1. The “Conference Declined” message is 


automatically sent to inviter. 





Contract: C37 terminateConferenceButtonEvent () 


Cross Reference: UC-4: Terminate Conference 


Preconditions: 
1. s.getState() == confInProgress. 
Postconditions: 
1. c. terminateVTC () or c.terminateTelecon () is 
called. 
2. s.getState == ready. 


3. The “Conference Terminated” message is displayed. 





4. The VTC/Telecon Icon is removed g.VTfCIcon() = 
FALSE or g.teleconICON() == FALSE. 


Contract: C38 c.terminateVTC () 
Cross Reference: UC-4: Terminate Conference 
Preconditions: 

1. terminateConferenceButtonEvent () has been called. 
Postconditions: 

1. v.terminateVTC() is called. 


2. s.getState == vtcTerminated. 


Contract: C39 c.terminateTelecon () 
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Cross Reference: UC-4: Terminate Conference 
Preconditions: 

1. terminateConferenceButtonEvent () has been called. 
Postconditions: 

1. t.terminateTelecon() is called. 


2. s.getState == teleconTerminated. 


Contract: C40 v.terminateVTC () 
Cross Reference: UC-4: Terminate Conference 
Preconditions: 

1. c.terminateVTC() has been called. 

2. s.getState == vtcTerminated. 
Postconditions: 


1. v is destroyed. 


Contract: C41 t.terminateTelecon () 
Cross Reference: UC-4: Terminate Conference 
Preconditions: 
1. c.terminateTelecon() has been called. 
2. s.getState == teleconTerminated. 
Postconditions: 
1. The call is disconnected call.bye(). 


2.t is destroyed. 
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Contract: C42 searchButtonEvent (unitName) :Unit 
Cross Reference: UC-6: Query Directory 
Preconditions: 

1. An instance d of DirectoryManager exists. 

2. An instance u of Unit exists. 
Postconditions: 

1. d.search (unitName) is called. 


2. The appropriate entry is highlighted in the 


Directory table. 


3. The unit’s telephone Number is placed in the dial 


textbox. 


Contract: C43 search(unitName) :void 
Cross Reference: UC-6: Query Directory 
Preconditions: 
a. An instance d of DirectoryManager exists. 
b. An instance u of Unit exists. 
Postconditions: 
1. u.getTelNum(unitName) is called. 


2. The appropriate entry is highlighted in the 


Directory table. 


3. The unit’s telephone Number is placed in the dial 


textbox. 


Contract: C44 getTel(unitName) :Unit 
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Cross Reference: UC-6: Query Directory 
Preconditions: 
1. An instance d of DirectoryManager exists. 
2. An instance u of Unit exists. 
Postconditions: 


1. The unit’s telephone number is returned. 


Contract: C45 open() :void 
Cross Reference: UC-11 Login 
Preconditions: 

1. Application is running. 
Postconditions: 


1. GUI display format is set and visible. 


Contract: C46 openResource() :void 
Cross Reference: UC-11 Login 
Preconditions: 
1. Login is complete and GUI is displayed. 
Postconditions: 


1. Contacts list file is opened. 


Contract: C47 refreshList() :void 
Cross Reference: UC- 7 Update Directory 
Preconditions: 
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1. GUI is displayed. 
2. Contact list is opened. 
Postconditions: 


1. Directory entries in the GUI are refreshed. 


Contract: C48 createTree() :void 


Cross Reference: UC-7 Update Directory 


Preconditions: 


1. Contact list is opened. 


Postconditions: 
1. Unsorted array £ units created for map 
construction. 
2. phoneNum, ipAddress, unitMap, and dialMap 


TreeMaps created. 


Contract: C49 displayDirectory() :void 
Cross Reference: UC-6 Query Directory 
Preconditions: 

1. Contact list is open. 

2. unitArray created. 
Postconditions: 


1. The directory is displayed in the GUI. 
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Contract: C50 initialize() :void 

Cross Reference: UC-11 Login 

Preconditions: 
1. Login successful. 

Postconditions: 
1. An instance ec of ConnectionManager is created. 
2. An instance d of DirectoryManager is created. 
3. An instance g of GuiEventHandler is created. 
4. An instance s of StateMachine is created. 
5. An instance call of Call is created. 
6. call.Listen(). 


7. s.setState (ready). 


Contract: C51 ruleViolation() :void 
Cross Reference: UC-2 Initiate Conference 
Preconditions: 

1. User attempts to initiate a conference. 


2. User already engaged in a teleconference or VIC. 








Postconditions: 
1. Error message displayed. 


2. No conference initiated. 


Contract: C52 incomingCall() :void 
Cross Reference: UC-lb. Receive Call 
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Preconditions: 





1. Call request received from caller. 

2. Session Descriptor is retrieved. 
Postconditions: 

1. Call is accepted or refused. 


2.A new instance m of Message is created if the 


callee is in a conference. 


Contract: C53 callTerminated() :void 
Cross Reference: UC-l1.c 
Preconditions: 

1. s.GetState(callinProgress). 
Postconditions: 

1. s.setState(callTerminated). 

2. call.hangup(). 


3. s.setState (ready) 


Contract: C54 getName() :void 
Cross Reference: UC-6 Directory Query 
Preconditions: 

1. initialize() has been called. 

2. An instance u of Unit exists. 
Postconditions: 


1. unitName is returned. 


165 


Contract: C55 hangUp() :void 
Cross Reference: UC-l1.c 
Preconditions: 

1. s.GetState (callInProgress) 
Postconditions: 

1. call is terminated. 

2. call.listen(). 


3. s.setState (ready). 


Contract: C56 printLog() :void 
Cross Reference: UC-1,2,3 
Preconditions: 


1. Call/VTC/Telecon request is received 


call/VTC/Telecon invitation is sent. 
Postconditions: 


1. Call log is updated with call information. 


Contract: C57 ring() :void 
Cross Reference: UC-1 
Preconditions: 

1. A call has been initiated. 
Postconditions: 


1. Ring wav file is played. 
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or 


Contract: C58 cancelTelecon() :void 
Cross Reference: UC-2b 
Preconditions: 

1. An instance t of Telecon exists. 
Postconditions: 

1. s.setState (teleconTerminated). 


2.¢€ is destroyed. 


Contract: C59 conductTelecon() :void 
Cross Reference: UC-3a Accept Telecon Invite 
Preconditions: 
1. An instance t of Telecon exists. 
2. isOnCall (true) 
Postconditions: 


1. s.getState (teleconInProgress) . 


Contract: C60 cancelVTIC() :void 
Cross Reference: UC-2a VIC Invite 
Preconditions: 

1. An instance v of VIC exists. 

2. isOnCall (true). 
Postconditions: 

1. s.setState (vtcTerminated). 
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2.v is destroyed. 


Contract: C61 conductVTC() :void 
Cross Reference: UC-3a Accept VTC Invite 
Preconditions: 
1. An instance v of VIC exists. 
2. isOnCall (true) 
Postconditions: 


1. s.getState(vtcInProgress). 
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H. STATEMACHINE STATE DIAGRAM 
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Figure 45. VoIPNET State Diagram. 
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Vv. SOFTWARE TESTING PLAN 


A. INTRODUCTION 


ne Objectives 


This section describes, at a high level, the scope, 
approach, resources, and schedule of the testing 
activities. It provides a concise summary of the test plan 


objectives, the products to be delivered, major work 








activities, major work products, major milestones, required 
resources, and master high-level schedules, and effort 


requirements. 


2. Testing Strategy 


Testing is the process of analyzing a software item to 
detect the differences between existing and required 


conditions and to evaluate the features of the software 





item. 


3. Scope 


This section specifies the plans for producing both 
scheduled and unscheduled updates to the Software Test Plan 
(change management). Methods for distribution of updates 
will be specified along with version control and 
configuration management requirements. Testing will be 
performed at several points in the life cycle as the 
product is constructed. Testing is a very ‘'dependent' 


activity. As ae result, test planning is a continuing 





activity performed throughout the system development life 





cycle. Test plans will be developed for each level of 


product testing (IOT&E/OT&E). All updates to the test plan 
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must be approved by the Test Coordinator and distributed to 
all testing agencies. If an impact to the Project Schedule 
is anticipated then the change must be proposed to all 


stakeholders for consideration and approval. The Project 





Manager will update the schedule and distribute in a timely 
fashion to all stakeholders. 
4. Reference Material 
[1] “VoIPNET Thesis Proposal.” Reiche. 
[2] “VoIPNET Vision Document.” Reiche. 


[3] “VoIPNET Requirements Specification Document.” Reiche. 











[4] “VoIPNET Design Specification Document.” Reiche. 








[5] “IEEE Software Test Plan Template.” IEEE 829-1998 
Format. 


Di Definitions and Acronyms 


See Glossary. 


B. TEST ITEMS 


This section outlines the testing to be performed for 


VoOIPNET. 


1. Component Testing 


The RAT, VIC, GraphicalUA, NAD, and Rider components 
will be tested for suitability and functional correctness. 


Component testing will be conducted during IOT&E testing. 


2. Integration Testing 


The integration of RAT, VIC, Graphical UA, NAD and 
Rider will be tested. Integration testing will be conducted 


during IOT&E testing. 
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3. Recovery Testing 


A fully integrated VoIPNET application will be tested 
under network and peripheral failure conditions. Recovery 
Testing will be conducted during both IOT&E and OT&E 


testing. 


4. Performance Testing 


A fully integrated VoIPNET prototype will be tested 
under multiple network configurations and capacity. 


Performance Testing will occur during OT&E testing. 


Cc. APPROACH 


This section describes the overall approaches to 
testing. Testing will composed of two major test 
evolutions, IOT&E and OT&E. The Initial Operational Test 
and Evaluation (IOT&E) will be conducted in a laboratory 
environment, at Naval Postgraduate School, on a é100Mbs 
network with three (3) users. During IOT&E the Component, 
Integration, Recovery, and Performance tests will be 
conducted. Immediately upon completion of Testing the 
Analysis of all test data will begin. Prior to _ the 
execution of OT&E the IOT&E report must be completed and 
reviewed. Any recommended changes to the OT&E plan must 
then be submitted to the Test Coordinator and or Project 
Manager. All approved changes must be installed prior to 
the commencement of OT&E. 

Operational Test and Evaluation (OT&E) will be 
conducted, at Marine Corps Tactical Systems Support 
Activity (MCTSSA), in both a laboratory and field 
environment on a low bandwidth (<150Kbs) network (EPLRS 


Radio Network). During OT&E the Recovery and Performance 
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tests will be conducted. Upon completion of OT&E all test 
results will be analyzed and the OT&E Report will be 
generated. Following the review of the OT&E report, the 


IOT&E and OT&E reports will be included and summarized as 





part of the Comprehensive Test Report. 


D. PROCEDURAL CRITERIA 


The criteria used to determine whether the tested item 





has passed/failed testing. 


1: Test Suspension Criteria 


The criteria used to suspend all or a portion of the 


testing activity associated with a test item is as follows: 
Network becomes unstable. 
If two or more User Agents drop off of the network. 
Software Testing Tools are inoperable. 
Improper Activity Log Entry prior to commencement of 
testing event. 
2. Test Resumption Criteria 


The criteria used to resume all or a portion of the 
testing activity associated with a suspended test item is 


as follows: 


The Network Administrator must certify the network is 
stable and provide the Test Coordinator with the Network 


Configuration. 


The Test Coordinator must enter the corrective actions 
taken in the Test Activity Log and create a new entry for 


the next test. 
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3. Test Result Approval Criteria 


The test result approval process requires that all 
test results be verified in writing by the Network 
Administrator, Test Coordinator, and Test Approval 
Authority. Each test result must be accompanied by the 


network configuration and baseline capacity measurements. 


E. TESTING PROCESS 


This section identifies the methods and criteria used 
in the performance of test activities. It defines the 


specific tests and procedures for each type of test. In 





addition, it provides the detailed criteria for evaluating 


test results. 


1, Primary Tasks 


This section identifies the primary testing tasks 


during the test process. 


e Conduct a Comprehensive Test of VoIPNET and provide 








deployment recommendations. 


e Conduct IOT&E Testing in order uuxe) determine 
suitability, ensure integration quality, record fault 
tolerance and compile performance characteristics. 
Detailed Test Plans can be found in Section I of this 


chapter. 
"= Conduct Component Testing 
*™" Conduct Integration Testing 
™" Conduct Recovery Testing 


™" Conduct Performance Testing 
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e Conduct OT&E Testing in order to record fault 
tolerance and compile performance characteristics on 
an EPLRS network. Detailed OT&E Test Plans can be 


found in section J of this chapter. 
™" Conduct Recovery Testing 


™" Conduct Performance Testing 


2. Supplementary Tasks 


Identifies all tasks, skills and dependencies 
necessary to prepare for and conduct testing activities. 


Supplementary tasks include: 


Software Tool Identification: identify the tools 


required to measure performance metrics. 


Software Packaging: consolidate all testable software 
packages, supporting components, and test tools into an 


easily deployable media. 


Facilities Coordination: coordinate the physical 


location for testing and storage of hardware. 


Special Skills required: An EPLRS network manager is 


required to install, operate and maintain the test network 


platform. 
3. Responsibilities 
Identify the groups responsible for managing, 


designing, preparing, executing, witnessing, checking, and 
resolving test activities. These groups may include 
developer, testers, operations staff, technical support 
staff, data administration staff, and user staff. The NPS 


Test Coordinator has overall responsibility for the 
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synthesis of all planning documents, test reports, and 
recommendations. In addition, the NPS Test Coordinator will 
supervise and/or conduct the preparation and execution of 


all test activities. 


4. Resources 


Identifies the resources allocated for the performance 
of testing tasks. Identifies the organizational elements or 


individuals responsible for performing testing activities. 





Assigns specific responsibilities and specifies resources 


by category. 


Testing Responsibility 

Initial Operational Test and Evaluation (IOT&E)- IOT&E 
will be conducted at the Naval Post Graduate School under 
the supervision of the NPS Testing Coordinator. 

Operational Test and Evaluation (OT&E)- OT&E will be 
conducted at MCTSSA, Camp Pendleton, CA, under the joint 
supervision of the NPS Test Coordinator and the MCTSSA 
EPLRS Coordinator. The below resources and the 
corresponding responsible authority are required to conduct 


the testing. 


Resource Categories 
Infrastructure: 
Storage/Lab Space- MCTSSA 
Operator Support- MCTSSA 


Hardware: 
EPLRS Systems-— MCTSSA 


Break-out Boxes-—- MCTSSA 
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Net Manager IOW and Software- MCTSSA 
Personal Computers- NPS 

Routers-— NPS 

USB Hub- NPS 

USB Headsets-— NPS 

USB WebCams-— NPS 

Cat-5- NPS 


Software: 
VoIPNET Software package- NPS 
Robust Audio Tool Software package- NPS 
Video Conference Software package- NPS 
Rider Software Package- NPS 


Net Activity Diagram-— NPS 


MCTSSA Support Coordinator: Captain Jeffery Wrobel/USMC, 


MCTSSA EPLRS Coordination Officer. 


MCTSSA Network Administrator: Mr. Pedro Zenquis 


NPS Testing Coordinator Captain Charles P. Reiche, Jr/USMC 


5. Schedule 


Identifies the high level schedule for each testing 
task. Establishes specific milestones for: 1) initiating 
and completing each type of test activity, 2) for the 


completion of the comprehensive test plan, and 3) for the 





delivery of test reports. Estimates of the time required to 








do each test activity are provided in the respective test 
plan. 


High-Level Testing Milestones: 
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e Comprehensive Testing Started 
o IOT&E Testing Started 
o IOT&E Testing Complete 
o OT&E Testing Started 


o OT&E Testing Complete 





e Comprehensive Test Complete 


6. Test Deliverables 


This section identifies the deliverable documents from 





the test process. 

IOT&E Testing Activity Report 

OT&E Testing Activity Report 
Component Testing Activity Report 
Integration Testing Activity Report 
Recovery Testing Activity Report 
Performance Testing Activity Report 


Comprehensive Testing Summary Report 





F. ENVIRONMENTAL REQUIREMENTS 
1. Hardware 


The computer and network requirements to complete 


testing activities include: 


EPLRS Radio (3-5) and associated SL-3 Components. 





Net Manager Intelligence Operations Workstation (1) 
PC-RT connection box (Breakout Box) (3-5) 
Windows configured Personal Computers (3-5) 


USB Plantronics DSP-400 VoIP headset (3-5) 
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USB WebCamera (3-5) 
Belkin USB Hub (1) 
Belkin/Cisco 4-6 port Router (1) 


Cat-5 w/rj-45 connectors (10 @ 20’ length) 


2. Software 





The Software requirements to complete testing 


activities include: 
VoIPNET (MJSIP GraphicalUA) 
Robust Audio Tool v4.2.24 
Video Component v2.8ucl1.1.6 
EPLRS Net Manager (ENM) 
Rider v11.50.0.45560 


Net Activity Diagram v2.3.0.293 


3. Security 

Testing environment security and asset protection 
requirements include a securable room for overnight storage 
of hardware. 

4. Tools 

There are no special software tools, techniques and/or 
methodologies employed in the testing effort. 

5. Publications 


Identify the documents and or publications required to 


conduct testing. 
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EPLRS RS Technical Manuals 

EPLRS Network Manager Technical Manual 

EPLRS Network Planner Technical Manual 

MCTSSA EPLRS Network Standard Operating Procedure 
Robust Audio Tool (RAT) Users Manual 

Video Component (VIC) Users Manual 


Codec Comparison Charts 





VoIPNET Comprehensive Test Plan 


6. Risks and Assumptions 


Identifies significant resource constraints, such as 
test item availability, testing facility availability, test 
resource availability, and time constraints. See the Risk 
Management Plan in Chapter IV. for detailed Risk 


assessments. 


MCTSSA Test Facility availability is only available 





for one business week. We have limited influence over test 





date adjustments. 


MCTSSA resource provisions are under the control of 
the EPLRS representative. Assets may be reallocated to 


support MCTSSA efforts. 

Testing must be completed by May 15, 2007, to allow 
for the synthesis and analysis of test reports. 
G. CHANGE MANAGEMENT PROCEDURE 


All changes to the test plan require approval of the 
corresponding Approval Authority as identified in Section H 


of this document. All approved changes will be incorporated 
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into the corresponding individual test plan and the 


Comprehensive test plan. Changes will be submitted to all 





participants in the testing process. 


H. TEST PLAN APPROVAL AUTHORITY 


The below personnel are authorized to approve changes 


to the VoIPNET Comprehensive Test Plan: 





Captain Charles P. Reiche, Jr/USMC 


The below personnel are authorized to approve changes 


to the VoIPNET Individual Test Plans: 


Captain Charles P. Reiche, Jr/USMC 


iL. IOT&E TEST PLAN 
1. Component Test Plan 


VERSION: 1.1 

DATE: April 7, 2007 

TEST COORDINATOR: Capt C.P. Reiche. JR 
PURPOSE 


The purpose of Component Testing is to ensure that 
each component meets the functional and non-functional 


requirements as defined in the Requirements Specification 





Document. 


ITEMS TO BE TESTED 


The RAT, VIC, GraphicalUA, NAD, and Rider components 
will be tested for suitability and functional correctness. 
Component testing will be conducted during IOT&E testing. 
FEATURES TO BE TESTED 
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This section identifies all features and specific 
combinations of features that will be tested under each 


test plan. 


GraphicalUA: The Call, Hangup, Directory Services, and 


Configuration File features will be tested. 


RAT: Talk checkbox, Options>Transmission>Audio 
Encoding, Options>Audio>Audio Device, Options>Audio>Sample 
Rate, Options>Audio>Channels, and Options>Security features 


will be tested. 


VIC: The Menu>Transmission Rate Slider, Menu>Frame 
Rate Slider, Menu>Transmit/Release Button, Menu>Global 
Statistics, Menu>Members, and Image View options will be 


tested. 


NAD: The General, Appearance, Filters, and 


Notifications Options will be tested for suitability. 


Rider: The Response, Bandwidth, VoIP, and Traceroute 
features will be tested for suitability. 


FEATURES NOT TO BE TESTED 


All features that will not be tested are identified. 





GraphicalUA: None. 


RAT: Options>Channel Encoding, Options>Reception, 
Options>Interface, Options>Codec Mapping, and Reception 


Quality Matrix. 
VIC: Menu>Encoder, Menu>Display, and Menu>Session. 
NAD: None. 


Rider: None. 


MANAGEMENT AND TECHNICAL APPROACH 
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Fach component will be tested independently for 
suitability and functionality during IOT&E. 
PASS / FAIL CRITERIA 


The criteria used to determine whether the tested item 





has passed/failed testing. 


VoIPNET: The call feature must connect to the correct 
addressee. The Hangup feature must disconnect the current 
call and return both UA’s (User Agents) to the listen 


state. The Directory Services feature must place the 





selected sip address into the dial text field. The 
Configuration File feature must configure the Graphical US 
with the correct settings. The contact list feature must 
install the correct contact list as identified in the 


configuration file. 


RAT: The CODEC selection feature correctly replaces 
the current CODEC with the selected CODEC. The Audio 
Options feature correctly adjusts the audio configuration 


settings. 


VIC: The Transmission Rate Slider correctly adjusts 
the transmission rate. The Frame Rate Slider correctly 
adjusts the video frame rate. The view image option 


correctly adjusts the viewing window. 


NAD: The settings feature correctly adjusts the 
General, Appearance, Filters, and Notifications settings. 

Rider: The Response feature provides accurate response 
times as verified with a standard ping test. The Bandwidth 
feature provides bandwidth estimates comparable to known 
standard technical capabilities. The VoIP test feature 


provides test results that coincide with observable 
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performance characteristics. The Traceroute feature returns 
a traceroute that matches the physical configuration of the 


network. 


INDIVIDUAL ROLES AND RESPONSIBILITIES 
The NPS Test Coordinator is responsible for 
application collection, Laboratory establishment, Testing 
and Report Generation. 
MILESTONES 
e Tested Software installed 
e Component Testing Started 
o GraphicalUA Test Started 
o GraphicalUA Test Complete 
o RAT Test Started 
o RAT Test Complete 
o VIC Test Started 
o VIC Test Complete 
o NAD Test Started 





o NAD Test Complete 
o Rider Test Started 
o Rider Test Complete 
o Test Result Analysis Started 
o Test Result Analysis Complete 
o Test Report Generation Started 
o Test Report Generation Complete 
e Component Testing Complete 
SCHEDULES 


Day 1- Component Testing 


RISK ASSUMPTIONS AND CONSTRAINTS 


See Chapter IV. 
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2. Integration Test Plan 


VERSION: 1.2 

DATE: April 7, 2007 

TEST COORDINATOR: Capt C.P. Reiche. JR 
PURPOSE 


The purpose of Integration Testing is to ensure that 
the individual components perform as expected when fully 
integrated into VoIPNET. 

ITEMS TO BE TESTED 


The integration of RAT, VIC, Graphical UA, NAD and 
Rider will be tested. Integration testing will be conducted 
during IOT&E testing. 

FEATURES TO BE TESTED 


The Component Tests will be executed again after the 
individual components are integrated into a single 
application (VoIPNET). 

FEATURES NOT TO BE TESTED 


GraphicalUA: None. 

RAT: See Component Test plan. 
VIC: See Component Test Plan. 
NAD: None. 


Rider: None. 
MANAGEMENT AND TECHNICAL APPROACH 


Incremental development/testing will be utilized. As each 





component is integrated into the application, regression 
testing will done to ensure all features continue to 
function as required. Integration/Integration testing will 


occur in the following order: RAT, VIC, NAD, Rider. 
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PASS / FAIL CRITERIA 





The criteria used to determine whether the tested item 


has passed/failed testing. 





Each component must pass the respective Component Test 
following integration into the VoIPNET application without 
causing errors in the VoIPNET application and the 
integrated components. 

INDIVIDUAL ROLES AND RESPONSIBILITIES 

See Section G. 

MILESTONES 

e 512kbps network established 

e Integration Testing Started 
o GraphicalUA Test Started 
o GraphicalUA Test Complete 
o RAT Test Started 
o RAT Test Complete 
o VIC Test Started 
o VIC Test Complete 
o NAD Test Started 





o NAD Test Complete 

o Rider Test Started 

o Rider Test Complete 

o Test Result Analysis Started 

o Test Result Analysis Complete 

o Test Report Generation Started 

o Test Report Generation Complete 

e Integration Testing Complete 

SCHEDULES 


Day 1- Integration Testing 
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RISK ASSUMPTIONS AND CONSTRAINTS 


See Chapter IV. 


3. Recovery Test Plan 


VERSION: 1.1 

DATE: April 7, 2007 

TEST COORDINATOR: Capt C.P. Reiche. JR 
PURPOSE 


The purpose of Recovery Testing is to evaluate 
VoIPNET’s ability to recover from a variety of potential 
system errors. 


ITEMS TO BE TESTED 


A fully integrated VoIPNET application will be tested 
under network and peripheral failure conditions. Recovery 
Testing will be conducted during both IOT&E and OT&E 
testing. 

FEATURES TO BE TESTED 


The Dropped call recovery, Dropped VTC recovery and 
Network failure procedures will be tested. 


FEATURES NOT TO BE TESTED 


Nat, Firewall Traversal. 
MANAGEMENT AND TECHNICAL APPROACH 

The test technician will induce peripheral, Call, VTC 
and/or network faults. If the application fails to handle 
the errors in a graceful manner, the condition will be 
logged and a recommendation for correction must be provided 
in the Testing Report. 
PASS / FAIL CRITERIA 


The criteria used to determine whether the tested item 





has passed/failed testing. 
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A dropped call/VTC should return both UA’s to the 
listen state without error. A terminated VIC should not 


terminate the connected voice call. Network errors must not 





cause application errors aside from those expected 
communication errors due to network connectivity. 
INDIVIDUAL ROLES AND RESPONSIBILITIES 
See Section G. 
MILESTONES 
e 512kbps network established 
e Recovery Testing Started 
o Peripheral Failure Tests Started 
o Peripheral Failure Tests Complete 
o Network Failure Test Started 
o Network Failure Test Complete 
o Call Failure Test Started 
o Call Failure Test Complete 
o VIC Failure Test Started 
o VTC Failure Test Complete 
o Test Result Analysis Started 
o Test Result Analysis Complete 
o Test Report Generation Started 
o Test Report Generation Complete 
e Recovery Testing Complete 


SCHEDULES 





Day 2- Recovery testing 


RISK ASSUMPTIONS AND CONSTRAINTS 


See Chapter IV. 


4. Performance Test Plan 


VERSION: 1.2 
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DATE: May 7, 2007 
TEST COORDINATOR: Capt C.P. Reiche. JR 
PURPOSE 

The purpose of the Performance Test is to evaluate 
VoIPNET’s performance characteristics under various 
application and network configurations, in order to provide 


the optimal network and application configuration 





deployment recommendations. 


ITEMS TO BE TESTED 


A fully integrated VoIPNET prototype will be tested 
under multiple network configurations and capacity. 
Performance Testing will occur during OT&E testing. 


FEATURES TO BE TESTED 


The P2P Voice, VTC, VTC Conference, Call, and Hangup 
features will be tested. 


FEATURES NOT TO BE TESTED 


None. 
MANAGEMENT AND TECHNICAL APPROACH 

Performance will be tested and measured during IOT&E 
on a high bandwidth network as well as during OT&E on a low 
bandwidth network. Various CODEC, Transmission Rate, and 
Frame rate settings will be tested for both Low and High 
Bandwidth Networks. 
PASS / FAIL CRITERIA 


The criteria used to determine whether the tested item 





has passed/failed testing. 


Each Call must return a Quality of Service (QOS) 
Average -—> Good at 100 Kbps, Good -> Very Good at 256 Kbps, 
and Very Good at 512 Kbps 


190 


Bach VTC must return a QOS Average -> Good at < 
100kbs, Good -> Very Good at < 256kbs, and Very Good at 
512Kbs. 

INDIVIDUAL ROLES AND RESPONSIBILITIES 
See Section G. 
MILESTONES 
e Network Established 
e Performance Testing Started 
o Audio Test Started 
o 512kbps Network Emulation Established 
™" Audio Package 1 Started 
*™" Audio Package 1 Complete 
o 256kbps Network Emulation Established 
™" Audio Package 2 Started 
*™" Audio Package 2 Complete 
o 100kbps Network Emulation Established 
™ Audio Package 3 Started 
*™" Audio Package 3 Complete 


e Audio Test Result Analysis Started 


m 


e Audio Test Result Analysis Complete 


m 


e Audio Test Report Generation Started 


e Audio Test Report Generation Complete 





m 


e Audio Test Complete 
e VTC Test Started 
o 512kbps Network Emulation Established 
=» VTC Package 4 Started 
=" VIC Package 4 Complete 
o 256kbps Network Emulation Established 
=» VTC Package 5 Started 


=" VIC Package 5 Complete 
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o 100kbps Network Emulation Established 
=" VIC Package 6 Started 


=" VTC Package 6 Complete 


o VTC Test Result Analysis Started 

o VIC Test Result Analysis Complete 

o VIC Test Report Generation Started 
o VTC Test Report Generation Complete 
o VIC Test Complete 








e Performance Test Result Analysis Started 
e Performance Test Result Analysis Complete 
e Performance Test Report Generation Started 


e Performance Test Report Generation Complete 





m 


e Performance Testing Complete 
SCHEDULES 
Day 2- Audio Package 1, 2, and 3 
Day 3- Video Package 4, Video Package 5 


Day 4- Video Package 6 


RISK ASSUMPTIONS AND CONSTRAINTS 


See Chapter IV. 


J. OT&E TEST PLAN 
1. Recovery Test Plan 


VERSION: 1.1 

DATE: April 7, 2007 

TEST COORDINATOR: Capt C.P. Reiche. JR 
PURPOSE 


The purpose of Recovery Testing is to evaluate 
VoIPNET’s ability to recover from a variety of potential 
system errors. 
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ITEMS TO BE TESTED 


A fully integrated VoIPNET application will be tested 
under network and peripheral failure conditions. Recovery 
Testing will be conducted during both IOT&E and OT&E 
testing. 

FEATURES TO BE TESTED 


The Dropped call recovery, Dropped VTC recovery and 
Network failure procedures will be tested. 


FEATURES NOT TO BE TESTED 


Nat, Firewall Traversal. 
MANAGEMENT AND TECHNICAL APPROACH 

The test technician will induce peripheral, Call, VTC 
and/or network faults. If the application fails to handle 
the errors in a graceful manner, the condition will be 
logged and a recommendation for correction must be provided 
in the Testing Report. 
PASS / FAIL CRITERIA 


The criteria used to determine whether the tested item 





has passed/failed testing. 
A dropped call/VTC should return both UA’s to the 
listen state without error. A terminated VTC should not 


terminate the connected voice call. Network errors must not 





cause application errors aside from those expected 
communication errors due to network connectivity. 
INDIVIDUAL ROLES AND RESPONSIBILITIES 

See Section G. 


MILESTONES 
e 4 node EPLRS network established 


e Recovery Testing Started 


o Peripheral Failure Test Started 
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o Peripheral Failure Test Complete 

o Network Failure Test Started 

o Network Failure Test Complete 

o Call Failure Test Started 

o Call Failure Test Complete 

o VTC Failure Test Started 

o VTC Failure Test Complete 

o Test Result Analysis Started 

o Test Result Analysis Complete 

o Test Report Generation Started 

o Test Report Generation Complete 
e Recovery Testing Complete 


SCHEDULES 





Day 4- Recovery Test. 
RISK ASSUMPTIONS AND CONSTRAINTS 


See Chapter IV. 


2. Performance Test Plan 


VERSION: 1.2 
DATE: May 13, 2007 
TEST COORDINATOR: Capt C.P. Reiche. JR 
PURPOSE 

The purpose of the Performance Test is to evaluate the 
VoIPNET prototype’s performance characteristics under 
various application and network configurations, in order to 
provide the optimal network and application configuration 
deployment recommendations and Requirement updates for 


development. 
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ITEMS TO BE TESTED 


A fully integrated VoIPNET prototype will be tested 
under multiple network configurations and capacity. 
Performance Testing will occur during OT&E testing. 


FEATURES TO BE TESTED 


The P2P Voice, VIC Conference, Call, and Hangup 
features will be tested. 


FEATURES NOT TO BE TESTED 


None. 
MANAGEMENT AND TECHNICAL APPROACH 

A two phased approach to testing will be used. 
Configuration testing will be done to identify two 
candidate network configurations for follow on application 
testing. Secondly, various software CODEC, Transmission 
Rate, and Frame rate settings will be tested for both Low 
and High Bandwidth Networks. Once a suitable network is 
identified the configuration will remain unchanged. All 
configuration changes will then be VoIPNET software based. 


PASS / FAIL CRITERIA 


The criteria used to determine whether the tested item 





has passed/failed testing. 


Each Call must return a Quality of Service (QOS) 
Average -> Good at < 100 Kbps. 


Bach VTC must return a QOS Average -> Good at < 
100kbs. 
INDIVIDUAL ROLES AND RESPONSIBILITIES 

See Section G. 


MILESTONES 


e 4 node EPLRS Network Established 
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e Configuration Testing Started 


e Configuration Testing Complete 


e Performance Testing Started 


o Audio Test 


Audio 
Audio 
Audio 
Audio 
Audio 


Audio 


o Audio Test 


o VTC Test 


o VIC Test 
o Performance 
o Performance 
o Performance 


o Performance 


Started 


Package 1 Started 


Package 1 Complete 


Test 


Test 


Test 


Test 


Result Analysis Started 
Result Analysis Complete 
Report Generation Started 


Report Generation Complete 


Complete 


Started 


VTC Package 1 Started 





VIC Test 


TC Test 
TC Test 


TC Test 


Test 
Test 
Test 


Test 


TC Package 1 Complete 

Result Analysis Started 
Result Analysis Complete 
Report Generation Started 
Report Generation Complete 


Complete 


Result Analysis Started 
Result Analysis Complete 
Report Generation Started 


Report Generation Complete 


e Performance Testing Complete 


SCHEDULES 


Day 1- Configuration 


Day 2- Configuration 


Day 3- Configuration 


Day 4- Audio Package 


Testing 
Testing 
Testing 


1, VTC Package 1, Recovery Test 
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RISK ASSUMPTIONS AND CONSTRAINTS 


See Chapter IV. 
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VI. SOFTWARE TEST REPORT 


A. IOT&E REPORT 
1. Test Network Overview 


Network Emulator Software (Shunra) was utilized to 
mimic various Tactical Networks. Shunra possesses’ the 
ability to regulate bandwidth, inject packet loss and force 
latency into a network, in order to emulate actual network 
conditions. The test was conducted on an emulated 512kbps, 
256kbps and 128kbps networks. The EPLRS CSMA, zero hop 
network profile (56msec Latency/1-2% dropped packets) was 


used to get preliminary data on prototype suitability. 





192.168.2.3 


192.168.2.4 




















VTC 





192.168.2.5 


Figure 46. IOT&E Test Architecture. 
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2. Test Data 


There were no network difficulties. The Shunra network 


emulation software performed as expected. 


Component Test Report 

















Configuration Observation 

Package ID# Description Pass/Fail Activity Log 
UA 1 Call Test P 
UA 2 Hangup Test P 
UA 3 Directory Services Test P 
UA 4 Contact List Test P 
UA 5 Configuration File Test P 

Package ID# Description Pass/Fail Activity Log 
RAT 1 Talk Checkbox iz 
RAT 2 Options>Transmission> P 
RAT 3 .Audio Encoding P 
RAT 4 Options>Audio P 
RAT 5 >Audio Device P 
RAT 6 >Sample Rate P 
RAT 7 >Channels P 
RAT 8 Options>Security P 

Package ID# Description Pass/Fail Activity Log 
VIC ie Menu> P 
VIC 2 >Transmit/Release P 
VIC 3 >TX Rate Control P 
VIC 4 >Frame Rate Control P 
VIC 5 >Global Statistics P 
VIC 6 >Members P 

Package ID# Description Pass/Fail Activity Log 
NAD 1 General Settings Test P 
NAD 2 Appearance Settings Test P 
NAD 3 Filters Settings Test P 
NAD 4 Notifications Settings Test P 

Package ID# Description Pass/Fail Activity Log 
Rider 1 Response feature Test P 
Rider 2 Bandwidth feature Test P 
Rider 3 VoIP feature Test P 
Rider 4 Traceroute feature Test P 
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512Kbps Baseline Data Measurements 


Bandwidth: 512Kbps 
Latency: 50ms 
Packet Loss: 2% 


256Kbps Baseline Data Measurements 


Bandwidth: 512Kbps 
Latency: 50ms 
Packet Loss: 2% 


Audio Test Report 


Pkg 





Pkg 


ty 
WWWWWW NNNNNNNNNDND NY 
aQ 
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Sample 
ID# Network CODEC Rate Bandwidth Qos 
1 512Kbps Linear-16 8Khz 128 VERY GOOD 
2 512Kbps PCMU 8Khz 64 VERY GOOD 
3 512Kbps PCMA 8Khz 64 VERY GOOD 
4 512Kbps G.726-40 8Khz 40 VERY GOOD 
5 512Kbps G.726-32 8Khz 32 GOOD 
6 512Kbps G.726-24 8Khz 24 GOOD 
T 512Kbps G.726-16 8Khz 16 AVERAGE 
8 512Kbps DVI 8Khz 32 VERY GOOD 
9 512Kbps VDVI 8Khz 32 VERY GOOD 
10 512Kbps GSM 8Khz 13.2 VERY GOOD 
1. 512Kbps LPC 8Khz 5.6 POOR 
Sample 
ID# Network CODEC Rate Bandwidth Qos 
1 256Kbps Linear-16 8Khz 128 GOOD 
2 256Kbps PCMU 8Khz 64 VERY GOOD 
3 256Kbps PCMA 8Khz 64 VERY GOOD 
4 256Kbps G.726-40 8Khz 40 VERY GOOD 
5 256Kbps G.726-32 8Khz 32 GOOD 
6 256Kbps G.726-24 8Khz 24 GOOD 
7] 256Kbps G.726-16 8Khz 16 AVERAGE 
8 256Kbps DVI 8Khz 32 VERY GOOD 
9 256Kbps VDVI 8Khz 32 VERY GOOD 
10 256Kbps GSM 8Khz 132 VERY GOOD 
de 256Kbps LPC 8Khz 5.6 POOR 
Sample 
ID# Network CODEC Rate Bandwidth Qos 
1 128Kbps Linear-16 8Khz 128 GOOD 
2 128Kbps PCMU 8Khz 64 VERY GOOD 
ic) 128Kbps PCMA 8Khz 64 VERY GOOD 
4 128Kbps G.726-40 8Khz 40 VERY GOOD 
5 128Kbps G.726-32 8Khz 32 GOOD 
6 128Kbps G.726-24 8Khz 24 GOOD 


Pass/ Fail 


tu uu UU oo 


Pass/ Fail 


A} tu UM UU Uo DU 


Pass/ Fail 


tu tu UU UD 


Network 
128Kbps 
128Kbps 
128Kbps 
128Kbps 


vTC Test Report 


Pkg 


bs P PSP FP FS PB BP BP BP BP BP BP FP SB B BP FP BP HB BP SP BP SB BP BP FP PB PB BP BP BP B PB PB BW 


ID# 


RoR 
po MONDO B® WNP 


Network 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 


CODEC 
DVI 
VDVI 
GSM 
LPC 


CODEC 


Linear-16 


Linear-16 


Linear-16 


Linear-16 


Linear-16 


Linear-16 





Linear-16 


PCMU 
PCMU 
PCMU 
PCMU 
PCMU 

















QaAaaA AAANHDAAAAAAHAA 


Sample 
Rate Bandwidth 


8Khz 32 
8Khz 32 
8Khz eS tse2, 
8Khz 5.6 
TX/Frame 
Sample Rate 
Rate (Kbps/fps) 


Khz 512/15 
Khz 512/8 
Khz 512/4 
Khz 128/15 
Khz 128/8 
Khz 128/4 
Khz 64/4 

Khz bi2/ 15 
Khz 512/8 
Khz 512/4 
Khz 128/15 
Khz 128/8 
Khz 128/4 
Khz 64/4 

Khz 512/15 
Khz 512/8 
Khz 512/4 
Khz 128/15 
Khz 128/8 
Khz 128/4 
Khz 64/4 

Khz 512/15 
Khz 512/8 
Khz 512/4 
Khz 128/15 
Khz 128/8 
Khz 128/4 
Khz 64/4 

Khz 512/15 
Khz 512/8 
Khz 512/4 
Khz 128/15 
Khz 128/8 
Khz 128/4 
Khz 64/4 
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co oO oO oO ©O ©O © © © © © © © © © © © © © GO GO CGO GO GO GO WO WO GO CO CO GW CGO CO GW 





QOS 
VERY GOOD 
VERY GOOD 
VERY GOOD 

POOR 





Pass/ Fail 


Hy tu 'U td 


vv Uo we WP HwOenenenwsewenrinhtinhtwinsinhsnhsnwtienenuwentsninininienwsewmoenwtwienwtwientiensssetwth ty 


Pkg 


aw fF FF PF PP BP BP SP FP SB HB BP FP BP PB BP PB BP BP P SB BP BP FP SB HB BP BP BP SBP BP SB BP PB BP HB SP BP BP B B PB BW 


ID# 


WWW W 
Oo ©O YN OD 


is is is 
oO 


Es 


iS oh oe i 
OrAN nD oO FF WY F 


is 





a oo oO fs 
DO FPF oO © 
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rF oO oO OI Dd 
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I 
I 


Network 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
512Kbps 
256Kbps 
256Kbps 


CODEC 

- 726-24 
- 726-24 
- 726-24 
- 726-24 
- 726-24 
- 726-24 
- 726-24 
- 726-16 
- 726-16 
- 726-16 
- 726-16 
- 726-16 
- 726-16 
- 726-16 
DVI 
DVI 
DVI 
DVI 
DVI 
DVI 
DVI 
VDVI 
VDVI 
VDVI 
VDVI 
Vv 
Vv 
V 


QOaQAaaQaaQana aA AAAAAAA A 





DVI 











LPC 
LPC 
LPC 
LPC 
LPC 
LPC 
LPC 





Linear-16 





Linear-16 


TX/Frame 


Sample Rate 
Rate (Kbps/fps) 
8Khz 512/15 
8Khz 512/8 
8Khz 512/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 512/15 
8Khz 512/8 
8Khz 512/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 512/15 
8Khz 512/8 
8Khz 512/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 512/15 
8Khz 512/8 
8Khz 512/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 512/15 
8Khz 512/8 
8Khz 512/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 512/15 
8Khz 512/8 
8Khz 512/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 256/15 
8Khz 256/8 
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Actual 
fps 


QOS 
VG 
VG 

GOOD 
GOOD 
GOOD 
GOOD 

AVG 
VG 
VG 

GOOD 
GOOD 
GOOD 
GOOD 

AVG 
VG 
VG 

GOOD 
GOOD 
GOOD 
GOOD 

AVG 
VG 
VG 

GOOD 
GOOD 
GOOD 
GOOD 

AVG 
VG 
VG 

GOOD 
GOOD 
GOOD 
GOOD 
AVG 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 


Pass/ 
Fail 


bao a © 3 3 3 3 © © © © © © LY LW OL © LW OW © © OL © OO © © © © © OL © © © © © © © © A © YY v9) 


Pkg 
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Network 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 


CODEC 


Linear-16 


Linear-16 


Linear-16 





Linear-16 


PCMU 
PCMU 
PCMU 
PCMU 
PCMU 
PCMU 
PCMU 

















QaAaaAa AANHDAAAAAAAAAHAAAAAAAAAAHA A 
I) 
7 
Ww 
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TX/Frame 


Sample Rate 
Rate (Kbps/fps) 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 256/15 
8Khz 256/8 
8Khz 256/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 256/15 
8Khz 256/8 
8Khz 256/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 256/15 
8Khz 256/8 
8Khz 256/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 256/15 
8Khz 256/8 
8Khz 256/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 256/15 
8Khz 256/8 
8Khz 256/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 256/15 
8Khz 256/8 
8Khz 256/4 
8Khz 128/15 
8Khz 128/8 
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Actual 
fps 


4 


ae 


QOS 
AVG 
AVG 
AVG 
GOOD 
BAVG 
AVG 
AVG 
AVG 
AVG 
AVG 
GOOD 
BAVG 
AVG 
AVG 
AVG 
AVG 
AVG 
AVG 
GOOD 
VG 
GOOD 
GOOD 
GOOD 
AVG 
VG 
GOOD 
GOOD 
VG 
VG 
VG 
VG 
VG 
GOOD 
GOOD 
VG 
VG 
VG 
VG 
VG 
GOOD 
GOOD 
VG 
VG 
VG 


Pass/ 
Fail 
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Pkg 
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ID# 


PPP P PP a) 
ae WN EOYM BARU BWBNHEeH FT 


Network 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
256Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 
128Kbps 


CODEC 
G.726-16 
DVI 
DVI 
DVI 
DVI 
DVI 
DVI 
DVI 














GSM 
LPC 
LPC 
LPC 
LPC 
LPC 
LPC 
LPC 





Linear-16 


Linear-16 


Linear-16 





Linear-16 


PCMU 
PCMU 
PCMU 
PCMU 
PCMA 
PCMA 
PCMA 
PCMA 
G.726-40 
G.726-40 
G.726-40 





TX/Frame 


Sample Rate 
Rate (Kbps/fps) 
8Khz 64/4 
8Khz 256/15 
8Khz 256/8 
8Khz 256/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 256/15 
8Khz 256/8 
8Khz 256/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 256/15 
8Khz 256/8 
8Khz 256/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 256/15 
8Khz 256/8 
8Khz 256/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 
8Khz 64/4 
8Khz 128/15 
8Khz 128/8 
8Khz 128/4 





205 


Actual 
fps 


2-3 


QOS 
VG 
BAVG 
GOOD 
VG 
AVG 
AVG 
AVG 
VG 
BAVG 
GOOD 
VG 
AVG 
AVG 
AVG 
VG 
GOOD 
GOOD 
VG 
VG 
VG 
VG 
VG 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
AVG 
GOOD 
POOR 
POOR 
AVG 
GOOD 
BAVG 
BAVG 
BAVG 


Pass/ 
Fail 
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ay 


The 


network. 


Integration or 
testing when a 
notification of a dropped call/VTC. 
in the next proposed release of VoIPNET. 
256kbps networks supported all the CODECS tested. 





Network CODEC 
128Kbps G.726-32 
128Kbps G.726-32 
128Kbps G.726-32 
128Kbps G.726-32 
128Kbps G.726-24 
128Kbps G.726-24 
128Kbps G.726-24 
128Kbps G.726-24 
128Kbps G.726-16 
128Kbps G.726-16 
128Kbps G.726-16 
128Kbps G.726-16 
128Kbps DVI 
128Kbps DVI 
128Kbps DVI 
128Kbps DVI 
128Kbps VDVI 
128Kbps VDVI 
128Kbps VDVI 
128Kbps VDVI 
128Kbps GSM 
128Kbps GSM 
128Kbps GSM 
128Kbps GSM 
128Kbps LPC 
128Kbps LPC 
128Kbps LPC 
128Kbps LPC 
Findings 


VoOIPNET Prototype was tested 


No 


issues 


Recovery testing. 


TX/Frame 





network failure was induced, 


Sample Rate Actual Pass/ 
Rate (Kbps/fps) fps Qos Fail 
8Khz 128/15 4-5fps POOR F 
8Khz 128/8 4-5fps POOR EF 
8Khz 128/4 4fps GOOD P 
8Khz 64/4 2-3fps VG P 
8Khz 128/15 6-7fps BAVG F 
8Khz 128/8 5-6fps BAVG F 
8Khz 128/4 4fps AVG P 
8Khz 64/4 2-3fps VG P 
8Khz 128/15 6-7fps POOR FE 
8Khz 128/8 5-6fps POOR EF 
8Khz 128/4 4fps BAVG P 
8Khz 64/4 2-3fps AVG P 
8Khz 128/15 6-7fps POOR F 
8Khz 128/8 4-6fps BAVG F 
8Khz 128/4 4fps BAVG F 
8Khz 64/4 2fps VG P 
8Khz 128/15 6-7fps POOR EF 
8Khz 128/8 4-6fps POOR F 
8Khz 128/4 4fps BAVG P 
8Khz 64/4 2fps VG P 
8Khz 128/15 5-6fps POOR FE 
8Khz 128/8 6-7fps POOR EF 
8Khz 128/4 4fps AVG P 
8Khz 64/4 2-3fps VG P 
8Khz 128/15 5-6fps POOR EF 
8Khz 128/8 6-7fps POOR EF 
8Khz 128/4 4fps POOR F 
8Khz 64/4 2-3fps POOR F 

on each emulated 
or surprises during Component, 
However, during recovery 


there was no 


This will be addressed 


The 512kbps and 


However, 


the LPC CODEC failed due to very poor voice quality and was 
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excluded from further testing. VIC tests showed Video 


Transmit rates that approached or exceeded capacity greatly 





degraded service quality. Therefore, it is recommended that 


each OT&E test use the following formula: 
TX rate = .95(Network Capacity - CODEC Bandwidth) 


The .95 allows a 5% overhead “buffer.” Network Capacity is 
the available network bandwidth. Finally, CODEC Bandwidth 
is the bandwidth each codec consumes at its corresponding 


sample rate. 


In addition, the 30, 15 and 8 fps settings proved to 
be less efficient on the 512/256kbps network 
configurations. When data rates approach 512 and 256kbps, 
the maximum frame rates available peek at 12 and 8 fps 


respectively. Data showed no increase in quality at the 





higher frame rate. Therefore, it is recommended that 30fps 


settings be removed from OT&éE tests. 


The Linear-16 (128kbps) and U/A-Law(64kbps) CODECS 
were successful but the increase in quality was not 
sufficient to justify the excess bandwidth required. The 
GSM CODEC was the most efficient and effective CODEC 
tested. On the lower bandwidth networks it was the only 
CODEC that provided clear voice at low bandwidth 


consumption (18kbps). 


The 128kbps network test proved to be the most useful. 
When bandwidth is this restricted, it is critical that the 


vTC transmit and frame rates be regulated to maximize the 





quality. At 128kbps the 4fps setting was the preferred 
setting. When VTC transmit rates approached network 


capacity the video quality degraded quickly. At this data 
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rate I found that it was most efficient and effective to 
restrict the VTC down to 64Kbps and 2 fps. At this low 
transmit rate an increase in frame rate does not have a 


corresponding increase in video quality. 
4. Recommendations 
Audio 
e Use the GSM CODEC only for OT&E testing 


e LPC CODEC is unacceptable. Drop the LPC CODEC 


from OT&E testing. 


e Use 8khz sampling only. 16 and 32khz will only 
serve to double and quadruple the bandwidth 


required. 


e To successfully regulate the bandwidth the 


maximum VTC transmit rate should be: 
vTC Tx rate =.95(Capacity - CODEC Bandwidth). 
e On larger capacity tactical networks (512- 


256kbps) use only the 128kbps/4fps or 64kbps/2fps 
VTC settings. 


e On smaller capacity tactical networks (<128kbps) 


use on the 64kbps/2fps VIC settings. 


e If a high quality VIC circuit is established 
follow these setting guidelines for efficiency 


and quality: 
=» 512Kbps yields a maximum of 12 fps 


=" 256Kbps yields a maximum of 8fps 
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*»" 128 kbps yields a maximum of 4fps 
" 64kbps yields a maximum of 2-3 fps 


e Use 50kbps @2fps for OT&E testing 
Requirements Update 


None. 


B. OT&E REPORT 
1. Test Network Overview 


The OT&E testing was conducted on multiple EPLRS 
network configurations. CSMA and MSG networks were 
established to mimic an Infantry Battalion organization. 
The networks were composed of a CSMA or MSG needline, 5 


RSs, 4 host computers, an EPLRS Network Monitor(ENM) and 





audio/video peripherals for each 3 hosts. The ENM was 
connected to an RS and on its own needline. This ensured it 


was not connected to the test network but was still able to 





make configuration changes to the tested Network. 


The CSMA and MSG LTS, waveform and hop settings were 
then changed to identify the best network configuration. 


The Rider software component was used to take measurements 





for latency, packet loss, and available bandwidth. The 
Network activity Diagram software was also used to confirm 


real-time bandwidth consumption. In addition, once an 





effective network was discovered, a CSMA multi-hop test was 
conducted at 0, 2 and 4 hops respectively. No MSG multi-hop 
test was conducted do to SME knowledge gap of applicable 
settings and configurations. Below are the specifics of the 


network architecture: 
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CSMA/MSG 
WE- 14 
LTS-4 
127.0.6.1 








VTC 


Figure 47. OT&E Test Architecture. 


2. Test Data 

Configuration Test 1: 
Network Type: MSG 
LTSs: 2 


Waveform Mode: 9 
210 


hop/relay: 2/1 


Baseline Measurements: 





Bandwidth: not measured 
Latency: not measured 
Packet Loss: not measured 


Result: Fail. Network would not establish. Not 
all RSs could be brought into net. No Host was brought into 


net, therefore a baseline measurements could not be taken. 





Configuration Test 2: 
Network Type: MSG/CSMA 
LTSs: 4 
Waveform Mode: 9 


hop/relay: 2/1 





Baseline Measurements: 
Bandwidth: 64Kbps 
Latency: 52ms 
Packet Loss: 1% 


Result: PASS. All RSs and hosts brought onto the 
network. Successful VTC conducted with 50Kbps @2fps 
transmit rate. Static on calls was traced to RF 
interference from the RSs. The RS power setting was changed 
from Med-high to low. This resolved the static issue and 


produced clear calls. Call behaved as half-duplex. Echo 





suppression was turned off and this resolved the problem. 
Configuration Test 3: 


Network Type: MSG/CSMA 
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LTSs: 7 
Waveform Mode: 9 
hop/relay:2/1 


Baseline Measurements: 





Bandwidth: not measured 
Latency: not measured 
Packet Loss: not measured 
Result: Fail. Failed to establish network. 
Configuration Test 4: 
Network Type: MSG/CSMA 
LTSs: 4 
Waveform Mode: 14 
hop/relay: 2/1 
Echo Suppression: OFF 


Baseline Measurements: 





Bandwidth: 64kbps 
Latency: 21ms 
Packet Loss: 1% 


Result: PASS. Echo suppression was turned off and 
this resolved the half-duplex problem. Successful VTC 
slightly pixilated with 50Kbps @ 2fps. 


Configuration Test 5: 
Network Type: MSG/CSMA 


LTSs: 2/4 
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Waveform Mode: 14 
hop/relay: 2/1 


Baseline Measurements: 





Bandwidth: 18kbps 
Latency: 177ms 
Packet Loss: 5% 


Result: FAIL. Very Poor VIC and voice. 5-8 second 


delay on voice and 30 second delay on video. 
Configuration Test 6: 
Network Type: MSG/CSMA 
LTSs: 4/2 
Waveform Mode: 14 
hop/relay: 2/1 
shares: 4/4/1/1 


Baseline Measurements: 





Bandwidth: 64kbps 
Latency: 104ms 
Packet Loss: 2% 


Result: PASS. Successful VTC with TX rate 40kbps 


@ 2fps. 
Configuration Test 7: 
Network Type: MSG/CSMA 
LTSs: 4/4 


Waveform Mode: 14 
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Routes: MSG-Programmed/CSMA-default 


hop/relay: 2/1 


Baseline Measurements: 





Bandwidth: 64kbps 
Latency: 53ms 


Packet Loss: 1% 


Result: PASS. Successful VTC with TX rate 50kbps 


@ 2fps. Excellent guality VoIP 


configuration tested. 
Configuration Test 8: 
Network Type: MSG/CSMA 


LTSs: 8/4 


Routes: MSG-programmed/CSMA-default 


Waveform Mode: 14 


hop/relay:2/1 





Baseline Measurements: 
Bandwidth: 64kbps 
Latency: 49ms 


Packet Loss: 1-2% 


Result: PASS. Network established. 


VIC 


Best MSG 


resulted 


40kbps variation in transmit rate and a 2fps variation in 


frame rate. 2-3 second delay in audio and 2 second delay in 





pixilated video. 
Configuration Test 9: 


Network Type: MSG/CSMA 
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LTSs: 8/4 

Routes: MSG-programmed/CSMA-programmed 
Waveform Mode: 14 

hop/relay: 2/1 


Baseline Measurements: 





Bandwidth: 64kbps 
Latency: 54ms 


Packet Loss: 2% 


Result: PASS. Same results as test #8. 


transmit rat had 15kbps variation. 
Configuration Test 10: 
Network Type: MSG/CSMA 
LTSs: 4/2 
Routes: MSG-programmed/CSMA-default 
Waveform Mode: 14 
hop/relay: 2/1 
shares: 2/2/1/1 


Baseline Measurements: 





Bandwidth:18.6 
Latency: 159ms 


Packet Loss: 2% 


Video 


Result: Fail. Insufficient bandwidth to conduct 


VTC test. 
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Configuration Test 11: 
Network Type: MSG/CSMA 
LTSs: 4/2 
Routes: MSG-programmed/CSMA-default 
Waveform Mode: 14 
hop/relay: 2/1 
shares: 4/4/1/1 


Baseline Measurements: 





Bandwidth: 64kbps 
Latency: 137ms 
Packet Loss: 1% 


Result: FAIL. No successful VTC. 30 Second Video 


delay. No audio with the VTC. 


Configuration Test 12: 
Network Type: CSMA/MSG 
LTSs: 4/4 
Routes: CSMA-programmed/MSG-—default 
Waveform Mode: 14 
hop/relay: 1/0 


Baseline Measurements: 





Bandwidth: 142Kbps 
Latency: 5ms 


Packet Loss: .17% 
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Result: PASS. Best network yet. Observed 
bandwidth as high as 185kbps. Conducted successful VIC. 


Will conduct detailed package tests on this network. 
Configuration Test 13: 
Network Type: CSMA 
LTSs:4 
Waveform Mode: 9 
hop/relay: 1/0 


Baseline Measurements: 





Bandwidth: 52kbps 
Latency: 21ms 
Packet Loss: 1% 


Result: PASS. Conducted successful VIC. No 


noticeable difference in quality or metrics from Test # 12. 
Configuration Test 14: 
Network Type: CSMA 
LTSs: 8 
Waveform Mode: 9 
hop/relay: 1/0 


Baseline Measurements: 





Bandwidth: not measured 
Latency: not measured 
Packet Loss: not measured 


Result: FAIL.Could not establish network. 
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Configuration Test 15: 
Network Type: CSMA 
LTSs: 4 
Waveform Mode: 9 
hop/relay: 2/1 


Baseline Measurements: 





Bandwidth: 30kbps 
Latency: 190ms 
Packet Loss: 2.1% 


Result: PASS. Successful VTC. Demonstrates multi- 


hop capability with CSMA. 
Configuration Test 16: 
Network Type: CSMA 
LTSs:4 
Waveform Mode: 9 
hop/relay: 4/3 


Baseline Measurements: 





Bandwidth: 16Kbps 


Latency: 227ms 


ole 


Packet Loss: 2.3 


Result: FAIL. Voice was choppy with 5 second 


delay. Performance commensurate with CSMA relay 
specifications. 
Summary 
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Several configurations successfully conducted a VTC 


but only one CSMA and one MSG configuration will be tested. 




















The networks were chosen based on capacity, packet 

latency, and video transmit rate stability. 

CSMA —- Test Configuration #12 

MSG - Test Configuration #7. 

CSMA — Test Configuration #15 (GSM CODEC ONLY) 

Test Coordinator: Captain C.P. Reiche, Jr Date: 
Network Administrator: Mr. Pedro Zenquis 

Audio Test Report 

Sample Qos Pass / 

Pkg ID# Network CODEC Rate CSMA MSG 
1 1 EPLRS Linear-16 8Khz GOOD POOR Pp 
1 2 EPLRS PCMU 8Khz GOOD POOR P 
1 3 EPLRS PCMA 8Khz GOOD POOR P 
1 4 EPLRS G.726-40 8Khz VG VG P 
1 5 EPLRS G.726-32 8Khz VG VG P 
1 6 EPLRS G.726-24 8Khz VG VG P 
1 7 EPLRS G.726-16 8Khz AVG AVG P 
1 8 EPLRS DVI 8Khz GOOD GOOD P 
1 9 EPLRS VDVI 8Khz GOOD GOOD P 
1 10 EPLRS GSM 8Khz VG VG P 
4 44 EPLRS Epes Skhe 

Video Test Report 

TX/Frame 
Rate F/S Qos 

Pkg ID# Network CODEC (Kbps/fps) CSMA/MSG CSMA MSG 
2 1 EPLRS Linear-16 128/15 4/4 POOR POOR 
2 2 EPLRS Linear-16 128/8 4/4 POOR POOR 
2 3 EPLRS Linear-16 128/4 4/4 POOR POOR 
2 4 EPLRS Linear-16 64/4 2-3/2-3 BAVG POOR 
2 5 EPLRS PCMU 128/15 4/4 POOR POOR 
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EPL 
EPL 
EPL 
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EPL 
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EPL 
EPL 
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EPL 
EPL 
EPL 
EPL 
EPL 
EPL 
EPL 
EPL 
EPL 
EPL 
EPL 
EPL 
EPL 
EPL 
EPL 
EPL 
EPL 





RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
RS 
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CODEC 
PCMA 
PCMA 
PCMA 


. 726-40 
- 726-40 
- 726-40 
- 726-40 
. 726-32 
- 726-32 
. 726-32 
. 726-32 
. 726-24 
- 726-24 
. 726-24 
. 726-24 
. 726-16 
- 726-16 
. 726-16 
- 726-16 


DVI 
DVI 
DVI 
DVI 
VDVI 
VDVI 
VDVI 
VDVI 
GSM 
GSM 





128/8 
128/4 
64/4 


TX/Frame 
Rate 
(Kbps/fps) 


128/8 
128/4 
64/4 
128/15 
128/8 
128/4 
64/4 
128/15 
128/8 
128/4 
64/4 
128/15 
128/8 
128/4 
64/4 
128/15 
128/8 
128/4 
64/4 
128/15 
128/8 
128/4 
64/4 
128/15 
128/8 
128/4 
64/4 
128/15 
128/8 
128/4 
64/4 
Res 
42848 
42844 
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4/4 
4/4 
2-3/2-3 


CSMA/MSG 


4 


4 


2-3/2-3 
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2-3/2-3 


4 
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2-3/2-3 
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2-3/2-3 
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POOR 
POOR 
POOR 


Pass/Fail 
CSMA/MSG 


POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
POOR 
BAVG 
POOR 
POOR 
POOR 
BAVG 
POOR 
POOR 
POOR 
GOOD 
POOR 
POOR 
POOR 
BAVG 
POOR 
POOR 
POOR 
BAVG 
BAVG 
BAVG 
BAVG 
VG 


F/F 
F/F 
P/F 


Pkg 
F/F 
F/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/P 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/F 
P/P 


VII. CONCLUSION 


A. FINDINGS 


A variety of MSG and CSMA network configurations were 


utilized to find the most efficient and effective network 





and application settings. Networks were tested at waveform 


modes 9/14 and 2/4/8 LTSs. Both waveforms provided maximum 





available bandwidth for the respective burst rate (2/4 ms). 


The MSG network is the theoretically preferred network 
configuration. Its membership restriction, guaranteed 
bandwidth, and “no bandwidth cost” multi-hop capability 
make it the most suitable for small tactical networks. The 
MSG network is not a network configuration that is 
frequently used by the U.S. Marine Corps. As a result the 
Subject Matter Experts (SMES) were unfamiliar with the 


configuration or administration of the network. This 





prevented extensive testing of a sole MSG network and 





required the use a variety of CSMA and MSG combinations. 


On all occasions regardless of network configuration, 
the attempt to configure an 8 LTS network failed. The 
network would not establish. According to published 
technical manuals this should have been an attainable 
configuration. In addition, any attempt to establish an MSG 
network without the inclusion of a CSMA on some variation 
of LTSs resulted in a failed network. On no occasion was 
the Network Administrator able to establish a viable 
network. I attribute this to lack of Network Administrator 
experience with the MSG network, and recommend that any 
follow-on researchers seek out an operator/planner with 
experience with this network configuration. In addition, 
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the use of a 2 LTS network resulted in maximum bandwidth of 
only 18kbps regardless of needline type therefore 
subsequent network configurations were not conducted with 


this setting. 


Most EPLRS technical publications recommend the 4ms 
waveform mode for streaming media. However, with regard to 


quality of VoIP services I found no discernible 





differences, excepting available bandwidth, between the 4ms 


and 2ms families of waveform modes. 


Tests were conducted on a network plan that included a 
CSMA network on 4 LTSs with programmed routes in addition 
to an MSG network with default routes only. Here after 
referred to as the CSMA/MSG network. This configuration 
should route VoIP traffic over the CSMA only. In addition, 
an MSG network with the same LTS configuration was tested. 
Here after known as the MSG/CSMA Network. The final network 
tested was a CSMA network with no MSG network. Here after 
known as the CSMA network. On each occasion the CSMA/MSG 
combination configuration provided greater bandwidth. While 
the MSG/CSMA configuration provided dedicated bandwidth to 


each user. 


Despite having no planned routes on the MSG portion of 
the network, some traffic was observed on the default 


routed network. The same observations were made on the CSMA 





portion of the MSG Network. Subject Matter Experts at 


MCTSSA could only speculate and not sufficiently explain 





this increase. I recommend follow-up researchers apply more 
sophisticated network monitoring tools in order to identify 
what traffic is traveling on which network and query 


Raytheon engineers regarding this observation. 
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The VoIPNET Prototype performed best when the CSMA/MSG 
and MSG/CSMA network was configured with 4 LTSs and 0 hops 


(CSMA only). However, 2 “voice only” calls were conducted 





via the CSMA/MSG 2 hop network with excellent results. The 
voice quality was excellent with no delay. Again, the 4Ms 


or 2Ms setting had no impact on quality. Baseline averages 





for both networks were: 
Bandwidth: CSMA-180kbps MSG-—64kbps. 
Jitter: 50-70 ms 
Packet loss: 1-2% 


The CSMA network supported 4 simultaneous “voice only” 
calls utilizing the GSM CODEC. The GSM CODEC proved to be 
the most efficient CODEC (18kbps) that provided the highest 
quality of service. The DVI, VDVI, U-Law, A-Law and G-726 
series CODECS were successful, but provided no noticeable 
increase in quality at a greater bandwidth cost. Calls were 
successfully conducted, with average quality when available 
bandwidth was as low as l16kbps. Based on call quality and 
baseline bandwidth measurements, the CSMA network 
configuration, in a laboratory environment, could support 6 
simultaneous “voice only” calls. Due to limitations in SME 
proficiency no threshold testing was conducted on the 


MSG/CSMA network. 


Both network configurations were able to support a 
Single VTC with audio. VTC quality was best at a 50kbps and 


2 frame/sec rate. Transmit/frame rates must be actively 





managed, as an unregulated VIC will consume excessive 
bandwidth and dramatically degrade network performance and 


capability. On the CSMA/MSG network 128kbps @ 2f/s video 
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throughput rates could be achieved, but at no significant 
improvement in quality and leaving no bandwidth for other 


users. The MSG/CSMA network is not capable of supporting 





transmit/frame rates greater than 40-50 kbps/2fps unless a 
tactically undesirable share allocation configuration is 
utilized. This configuration allocates all MSG share to two 
users and is in essence a High Data Rate Duplex circuit. 
In addition, regardless of network configuration the actual 
Transmit/frame rate of video data was 5-10% less than the 
connection capacity. The manual transmit and frame rate 
sliders in the prototype were utilized to find an 


acceptable rate. 


CODECS consuming more than 32kbps of bandwidth 
provided no measurable increase in quality. The GSM CODEC 
provided the best quality at the lowest bandwidth. On this 
EPLRS network, silence suppression was critical. Calls made 
without silence suppression used approximately 30% more 


bandwidth. Peripheral audio devices are subject RF 





interference when high power settings are used. When 
multiple radios were used in close proximity, a significant 
amount of static and interference can be heard. Excellent 
quality VoIP calls were supported using a 2 hop/ 1 relay 
network configuration. No VoIP calls were supportable when 


hops exceeded this configuration. 


CSMA needlines can support more voice only users than 


an MSG network. However an MSG network guarantees bandwidth 





to its users. Use CSMA if no user requires dedicated 


bandwidth and many users require the ability to transmit 





and receive. Use MSG if all users require dedicated 


bandwidth and only a few must transmit and receive. 
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B. CONCLUSION 


VoIP is an acceptable voice option for tactical 
networks. However, special care must be paid to ensure that 
the software employed has the capability to automatically 
adjust transmit and frame rates based on network health. 
This feature would optimize bandwidth utilization and 
increase quality. While the current version of EPLRS 
firmware supports VoIP, the current MSG network knowledge 
base prevents the use of an MSG network. The CSMA network 
does not provide sufficient bandwidth to take advantage of 
the multi-hop requirement in compartmentalized terrain 


(urban/mountain/ jungle). 


The VoIPNET prototype test results support the concept 
of VoIP via radio. While the existing firmware version 


requires detailed MSG network planning and highly efficient 





VoIP applications, it is feasible but not optimal. In a 
sparse CSMA network, the advantages gained by automatic 
relay and routing may be nullified. As the CSMA network 
increases in density, relays are more plentiful, but so are 
contentious users. I would not recommend a CSMA 
implementation for anything other than a small static 


network. 


In contrast, the MSG network has the potential to 


provide precisely the services required for VoIP. Circuit 








size may be tailored depending upon services required. 
Share allocation provides increased bandwidth to high 
priority users, while guaranteeing minimal bandwidth to 
lower priority shares. The “no-cost” multi-hop capability 
is ideal for compartmentalized terrain. The ability to 


automatically route communications is invaluable and will 
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greatly increase the reliability of infantry 
communications. VoIP is supportable using an MSG network on 
this version OL firmware. However, MSG network 
configuration expertise is not mature enough to support the 
advanced configuration requirements needed. Coordination 
with experienced MSG network planners is a requirement for 


future use of VoIP via the EPLRS tactical network. 
VoIPNET Requirement Updates 


The current prototype sends a "”BYE” message when one 
User Agent terminates the call. However, when the call is 
dropped by network or video peripheral failure, no status 


is sent. A VTC/Call status notification display would 





greatly increase the user’s situational awareness. Transmit 
and frame rate sliders must be included to efficiently 
manually adjust VTC quality based on network 
characteristics. The prototype tested proved the value of a 
graphically updateable CODEC library. The ability for an 
operator to manually change the CODEC based on Network 


conditions increases the efficiency of the application and 





utilization of network resources. 


An Automated continuous network health test will 
evaluate the health of the network for VoIP and 
automatically adjust the call variables, such as transmit 


rate, frame rate, and CODEC choice. This feature will 





ensure the efficient use of network resources. 
Deployment Recommendations 


VoIPNET should be deployed as an independent EPLRS 
network until the new firmware is fielded and 


interoperability is tested with existing Command = and 
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Control applications. Use CSMA if no user’ requires 
dedicated bandwidth and many users require the ability to 


transmit and receive. Maximum supportable is Bandwidth 





dependant. Use MSG if all users require dedicated bandwidth 


and only a few must transmit and receive. 


Use silence suppression and the mute button. It 
conserves bandwidth. In sparse networks use a dedicated 2 
hop/1 relay site with good LOS to the other RSs. For a CSMA 
network limit relays to 1 hop /0 relays or 2 hops/1 relay. 
Use shielded Audio/VTC peripheral components 
(headset/camera) or remote the RS to avoid RF interference 


when high power settings are used. 


To successfully regulate the bandwidth the VTC 


transmit rate should be: 
TX rate < .95 *(CAPCITY -— CODEC Bandwidth 


On Low bandwidth networks the overhead “buffer” may 


need to be increased to 10%, depending on network health. 
TX rate < .90(Capacity - CODEC Bandwidth) 


On larger capacity tactical networks (512-256kbps) 
keep the video transmit rates < 128kbps @ 4fps or < 40- 
50kbps @ 2fps respectively. On smaller capacity tactical 
networks (<128kbps) Video transmit rate should be 40-50kbps 
@ 2fps. 


Keep VTCs to a minimum. For every VTC (@50Kbps/2fps) 
2.5 voice calls can be supported. If a high quality VTC 


circuit is required use these guidelines for efficiency and 





quality: 


512Kbps yields a maximum of 12 fps 
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256Kbps yields a maximum of 8fps 
128 kbps yields a maximum of 4fps 


64kbps yields a maximum of 2-3 fps 


Cc. AREAS OF FUTURE STUDY 


The MSG network requires further study. VoIP service 
compatibility with the current version of EPLRS firmware 
requires that the MSG network be employed. Coordination 
with an MSG knowledgeable planner is required to complete 
the testing of VoIP services on the current firmware 
version. In addition, threshold testing and field testing 
would provide greater insight into the capabilities in a 
tactical environment. When the MSG network issues are 
resolved the next phase of testing should be in a field 


environment. 


Performance of EPLRS Radio Software Version 11.4.0.9.5 





The most recent release of EPLRS Firmware has specific 
VoIP support characteristics, to include 1Mbps needlines, 
Tactical Ad-Hoc Multiple Access Protocol (TAMA), weighted 
Node Activation Multiple Access (NAMA) Protocol, Multicast, 


and Fast Attach/Fast Release Service (SMSG). 





Multicast Capabilities 


Session management tools support multicast 
functionality. It may be possible to use a tool like SDR 
from UCL Media to broadcast a VTC to many users. I 
attempted to run SDR on the EPLRS networks but was unable 
to get the session advertisement to propagate through the 


network. The EPLRS firmware currently supports 15 multicast 
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routes. The new firmware supports 30. It would be a useful 
addition to the suite of audio and video tools if this 


could be resolved. 
EPLRS VoIP Threshold Testing 


Resource Limitations prevented the conduct of 
threshold/VoIP capacity testing on the EPLRS Network. The 
deployment recommendations found in this Thesis are 
preliminary and therefore must be followed up with 


comprehensive field testing. Of interest are the effects of 





topography/obstacles and maximum supportable VoIP users. 
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